Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt

[Olivier Bonaventure <[e-mail]>]

Joe, Yuchung,

> I suggest clarifying this as:
>
>     Once TSopt has been successfully negotiated (sent and received)
>     during the <SYN>, <SYN,ACK> exchange, TSopt MUST be sent in every
>     non-<RST> segment for the duration of the connection, and SHOULD be
>     sent in a <RST> segment (see Section 4.2 for details).

I fail to see the rationale for forcing a TCP connection to always send 
the TSopt in every segment. The timestamp aids to estimate the rtt and 
provides PAWS for long connections. Given the size of the TCP option 
space, we should not force the utilisation of the TSopt in all segments. 
Consider a TCP implementation that supports SACK, RFC1323 and TCP-AO or 
Multipath TCP. When this implementation sends an ACK segment that 
contains a SACK, is it better to encode a long SACK block or to use 
option space to encode a timestamp ? I'd vote for providing a timestamp 
from time to time and reporting accurate SACK blocks.


 > If a non-
 >     <RST> segment is received without a TSopt, a TCP MUST drop the
 >     segment
 >     and MAY also send an <ACK> for the last in-sequence segment.
 >     A TCP MUST NOT abort a TCP connection because any segment lacks
 >     an expected TSopt.

Dropping segments that do not contain the TSopt is excessive. There are 
on the Internet middleboxes that coalesce or split segments. While doing 
that, they may remove options. Dropping a segment because it does not 
contain the TSopt which is only informative appears overkill to me. 
Dropping a segment that does not contain the negotiated TCP-AO option 
makes sens, but not for the TSopt.


Olivier


-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be