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

[Pasi Sarolahti <[e-mail]>]

On May 24, 2013, at 10: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.

Always including TSopt seems to represent the rough consensus of the WG, even if it might not be a uniform agreement. This was discussed quite extensively some time ago. (Though judging rough consensus from Emails is difficult... we'd need some sort of electronic hum tool :-)

About your question: if you believe Multipath TCP is going to be useful for you, then it might be a reasonable choice to just disable timestamps entirely to make room for MPTCP and SACK, assuming the current work-in-progress spec. What do current MPTCP implementations do about this, by the way?

However...

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

MUST drop all (non-RST) segments without timestamp seems indeed excessive, and not very liberal in what you are accepting [RFC793]. Why is this needed? I don't see why "MUST be sent" on the sending side should imply "MUST drop" on the receiving side.

In the worst case this might discourage enabling timestamps at all, if an implementation wants to be safe against middleboxes as described.

- Pasi