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

[Yuchung Cheng <[e-mail]>]

On Fri, May 24, 2013 at 12:57 AM, Olivier Bonaventure
<[e-mail]> wrote:
> 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.

These are good points. Olivier are you suggesting to change MUST to SHOULD of
these two statements?
1.  TSopt MUST be sent in every non-<RST> segment
2. ... received without a TSopt, TCP MUST drop the segment

Richard: I do see middle-boxes (or receiver!) corrupt TS options, unfortunately.

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