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

["Scheffenegger, Richard" <[e-mail]>]

Hi Olivier,

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


We have been there; the interaction of multiple options used together was specifically stripped from this update. And randomly sending TSopt or not would break mechanisms like PAWS (and there might be others reliant on TSopt) - see below.


In that particular example you give, that implementation should choose to either limit TCP-AO to consume at most 20 bytes (to allow for 1 SACK block; the semantics of SACK will provide the most "important" blocks repeatedly), or to not use TSopt at all - still limiting TCP-AO to use no more than 32 bytes to allow for a single SACK block...



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

When TS is in use, the receiver will use the PAWS mechanism. Effectively, the TS becomes an extension of the sequence number. Accepting segments without TS could be seen like accepting a segment, where some (arbitrary) number of MSB bits in the sequence number are masked, and the remaining bits found to "probably" fall within the current window...


A middlebox should not strip TSopt if it ever let TSopt through. That is mentioned in section 6, but perhaps your view is that this is not emphasized enough? If a middlebox does remove TSopt any any non-<SYN>-only segment, it is broken and should be removed from the network.

If a middlebox chooses to split TCP segments (rather than IP packets), it needs to properly deal with TSopt too - putting that option, unaltered, in all the fragments created. If it doesn't, it is broken and should be removed.

One way of "motivating" the retirement of broken stuff is to point them out. 

Do you have any recent example of a broken middlebox that does not deal properly with TSopt?

Richard