[tcpm] draft-gont-tcpm-tcp-seq-validation

["Karen E. Egede Nielsen" <[e-mail]>]

Hi,



I have promised to review the draft draft-gont-tcpm-tcp-seq-validation.



Please accept the following comments to
draft-gont-tcpm-tcp-seq-validation-01.txt



General comments – “out of scope”:

-----------------------------------------------



The draft addresses “only” the left window side of the problem with
sequence number validation.

It could be appropriate also to address the following issues:



1.       An ACK which arrives with SEG.SEQ = RCV.NXT+RCV.WND and with no
data should be acceptable for processing

2.       (Possibly)  ACK which arrives with SEG.SEQ = RCV.NXT and with one
data byte should be acceptable for processing

3.  The unclarity of the following formulation of RFC793 (repeated also in
this draft) “Segments with higher beginning sequence numbers may

be held for later processing.



The first issue arise when there are packet drops. One way to address this
issue is to adjust the row on page 69:



          0      >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND



to



          0      >0     RCV.NXT =< SEG.SEQ =< RCV.NXT+RCV.WND



(Here disregarding the left side of the inequality). Our TCP implementation
follows this approach.



The second issue is relevant in order to allow for processing of delayed
ACK info sent in window-probes. The second issue would demand for an
adjustment of

the row

           >0       0     not acceptable



or possibly this is just a clarification of the text: “If the RCV.WND is
zero, no [data] segments will be acceptable, but
special allowance should be made to accept valid ACKs”.



The third issue is relevant to have clarified in order to ensure that ACK
information of OoO segments are processed immediately and that such
processing

not be subject to head-of-line blocking.



Detailed Comments – “in scope”:

---------------------------------------------



Simultaneous open situation, section 3.1:



The proposed solution does not accommodate for data sent together with SYN.



An alternative solution (I believe that this is our implementation choice)
is to accept the SYN, ACK segment if the segment is adjacent to the left
side of the window

[i.e., SEG.SEQ+SEG.LEN = RCV.NXT] in SYN-RECEIVED state. This solution is
robust towards SYN + DATA.



BR, Karen