1

I would like to understand how TCP receiver in established state should treat SACK information of out-of-order and fully within receive window segments,

where rcv_nxt < seq_no < rvc_nxt + win.

RFC793 specified how to deal with the following fields

  • how to process ack_no field
  • how to process window field
  • how to treat control bits (SYN, FIN, RST)
  • how to protect such fields from being updated by"old" segments, in case of reordering.

But RFC2018 does not specifies how process SACK information in a similar case.

Because limited option space in TCP header, SACK information may be distributed between number of segments, SACked data may reneged and so on.

What to do when belated segment arrives ? How to treat SACK information ? How to treat D-SACK information ? Cannot find proper references in RFC2018 and RFC 2883, please help.

4
  • 2
    Hi Elena and welcome to NE. What happens depends on the current state. Are you asking something not covered in the processing section of the TCP RFC? Have a look at p69 of tools.ietf.org/html/rfc793 NB: TCP deals in segments not packets.
    – jonathanjo
    Nov 14 '18 at 14:12
  • I have rewrited my question Nov 15 '18 at 10:56
  • Hi ... what cases are you thinking about? Simple packets out of order? Retransmissions? Duplicates?
    – jonathanjo
    Nov 15 '18 at 11:17
  • for instance 3 segments lost, so TCP receiver reports {block_a, block_b, block_c} in segment X, eventually lost segment between island_a and island_b arrive, so TCP receiver reports {block_ab, block_c} in segment X+1 but segment#1 and segments X and X+1 arrive reordered. Nov 15 '18 at 14:54
1

i think the short short answer is: an example of what sender can do is here rfc6675

First, TCP receiver does not process SACK fields. SACK, as ACK, is sent by the receiver, i.e., receiver creates information in SACK, and is processed by the sender.

On the receiver:

The actions of the receiver on duplicate packets do not depend on SACK option. TCP receiver should have its receiver buffer. Out-of-order segments within receiver window land in receiver buffer and await in-order-packets before these packets can be delivered to the application. SACK option merely specifies, that when the receiver creates an ACK, it can report that these packets are in the buffer (if this answers the question, you can stop reading).

Also, TCP receiver cannot distinguish between reordered packets and packet losses. So, the general actions are the same. Out-of-order segments are received. TCP acts as if some segments are missing unless they arrive sooner or later [*].

On the sender:

Actions of the sender on SACK segments are not important to the RFCs in question. The RFCs specify how sender can negotiate receiving SACK information from the receiver, should he want to do something with it. Usually, processing of SACK fields is part of the congestion control algorithm, or more precisely its loss recovery part. The congestion control employed by sender is sender's own decision (provided that it won't break the Internet) and is not negotiated. Thus, processing of SACKs is also sender's own decision. One such option is rfc6675. AFAIK the TCP implementation is not required to follow the spec precisely. Linux is slightly different.


[*] in modern TCP implementations this is not exactly true. Reordered packets can cause 3 dupacks and thus trigger actions of congestion control. The sender can utilize reordering detection (I think this is the rfc: rfc4015) that reverts actions of congestion control algorithm.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.