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.

  • 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 – Elena Gurevich 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. – Elena Gurevich Nov 15 '18 at 14:54

Your Answer

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

Browse other questions tagged or ask your own question.