TCP: retransmisions and ACK of remote messages - TCP-IP

This is a discussion on TCP: retransmisions and ACK of remote messages - TCP-IP ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: TCP: retransmisions and ACK of remote messages

  1. 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


  2. Re: TCP: retransmisions and ACK of remote messages


    michlemer@yahoo.fr writes:
    > 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?


    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



  3. Re: TCP: retransmisions and ACK of remote messages

    On Aug 30, 7:33 am, Ilkka Oksanen
    wrote:
    > michle...@yahoo.fr writes:
    > > 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?

    >
    > 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.


    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


  4. Re: TCP: retransmisions and ACK of remote messages

    Ilkka Oksanen writes:

    > michlemer@yahoo.fr writes:
    >> 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?

    >
    > 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


    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

  5. Re: TCP: retransmisions and ACK of remote messages

    On Sep 3, 6:29 pm, don provan wrote:

    > 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.


    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


+ Reply to Thread