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

[Christoph Paasch <[e-mail]>]

Hello,

On Mon, May 27, 2013 at 01:19:25PM +0300, Pasi Sarolahti wrote:
> On May 24, 2013, at 10:57 AM, Olivier Bonaventure
> <[e-mail]> wrote:
> >> 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?

the Linux Kernel implementation of MPTCP reduces the number of SACK-blocks
per packet, if the MPTCP-options need more space.

As we add an MPTCP DATA_ACK in each packet, if timestamps are enabled we
will set a maximum of 2 SACK-blocks per packet.

But this can probably be changed as described in Appendix A of RFC 6824.


Cheers,
Christoph