TCP: retransmisions and ACK of remote messages

Hello

Context: TCP segments containing data + Ack in both directions -> if
no segments lost both Seq & ack numbers increase each time
Question about retransmission cases:
As in our TCP implementation, the retransmission buffer is built
during the first transmit of the message, the retransmit buffer is
built with the ACK number of the last segment received at this time.
Afterwards other segments can be received so the ack number to send
increases.
If one of the previous segment to send is not acknoledged by the
remote, we need to retransmit it. Shall we update the ack number to
send according to the last segment received or can we keep the old
value which was set when the transmit segment was built?
(of course this only concerns retransmit segments, transmit segments
have the ack field updated)
Does anybody has any reference to a RFC about this topic? (I did not
find anything but I could have miss something).

Many thanks & best regards
Michel

[email]michlemer@yahoo.fr[/email] writes:[color=blue]
> If one of the previous segment to send is not acknoledged by the
> remote, we need to retransmit it. Shall we update the ack number to
> send according to the last segment received or can we keep the old
> value which was set when the transmit segment was built?[/color]

You should always send current value and not old. That will help
the other end to work optimally. Otherwise those retransmission can
be seen as duplicate ACKs that trigger fast retransmission
algorithms in remote host.

-ilkka

On Aug 30, 7:33 am, Ilkka Oksanen <ilk...@omppu.modeemi.cs.tut.fi>
wrote:[color=blue]
> michle...@yahoo.fr writes:[color=green]
> > If one of the previous segment to send is not acknoledged by the
> > remote, we need to retransmit it. Shall we update the ack number to
> > send according to the last segment received or can we keep the old
> > value which was set when the transmit segment was built?[/color]
>
> You should always send current value and not old. That will help
> the other end to work optimally. Otherwise those retransmission can
> be seen as duplicate ACKs that trigger fast retransmission
> algorithms in remote host.[/color]

I don't think these acks would trigger fast retransmission on the
other end.
1) these ACKs have already been superceded by other acks. Bytes
which /have/ been ACKed should never be retransmitted, fast nor
otherwise.
2) these ACKs will have data attached (len != 0). While not strictly
required (as far as I can tell), many stacks will not fast retransmit
based on arrival of these segments.

Having said that... Send the current ACK number.

/chris marget

Ilkka Oksanen <ilkkao@omppu.modeemi.cs.tut.fi> writes:
[color=blue]
> [email]michlemer@yahoo.fr[/email] writes:[color=green]
>> If one of the previous segment to send is not acknowledged by the
>> remote, we need to retransmit it. Shall we update the ack number to
>> send according to the last segment received or can we keep the old
>> value which was set when the transmit segment was built?[/color]
>
> You should always send current value and not old. That will help
> the other end to work optimally. Otherwise those retransmission can
> be seen as duplicate ACKs that trigger fast retransmission
> algorithms in remote host.
>
> -ilkka[/color]

Actually, it's worse that this. If two such implementations are
talking to each other, they'll dead lock if there's a lost ACK in each
direction. Each will repeatedly retransmit the stale ACK information
while continually receiving stale ACK information that tells it that
it needs to continue to retransmit the stale packet. And this is just
the most obvious of the possible problem.

Yes, by law, you need to transmit all the latest information in any
retransmission. (I'm not sure that particular "law" ever actually got
written up, but it's been reproved many times over the years.) It
turns out that, contrary to what your gut instincts might tell you,
retransmission is almost always easier when you implement it to
retransmit the correct *data* rather than retransmitting old
*packets*. Since that automatically gets you retransmitting all the
latest control information *and* results in the maximum packet size
(not just the size that you sent the first time), it's the way to go.

-don

On Sep 3, 6:29 pm, don provan <dpro...@comcast.net> wrote:
[color=blue]
> Yes, by law, you need to transmit all the latest information in any
> retransmission. (I'm not sure that particular "law" ever actually got
> written up, but it's been reproved many times over the years.) It
> turns out that, contrary to what your gut instincts might tell you,
> retransmission is almost always easier when you implement it to
> retransmit the correct *data* rather than retransmitting old
> *packets*. Since that automatically gets you retransmitting all the
> latest control information *and* results in the maximum packet size
> (not just the size that you sent the first time), it's the way to go.[/color]

Exactly. When you fail to see an expected acknowledged, you generally
follow a two-step process:

1) Update things to account for the loss of the packets. For example,
you may wish to back up your "last sent byte" to equal your "last
acknowledged byte".

2) Call your generic "send a packet" routine.

DS