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

Thanks,

I think Sally Floyd showed more than a decade ago, that the importance of subsequent SACK blocks (after the first) diminishes exponentially...

As long as there is room for one SACK block, SACK will work. The 2nd, 3rd... block will only add redundant information in case of ACK loss, but that information itself will be repeated eventually in the 1st SACK block (once the hole is filled).

Again, I am not supportive of using this as a reason to overhaul TSopt semantics in 1323bis as a whole... (probabilistic TSopt? Eventual PAWS?)

Richard Scheffenegger

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Christoph Paasch
> Sent: Montag, 27. Mai 2013 16:54
> To: Pasi Sarolahti
> Cc: tcpm@ietf.org Extensions; Joe Touch
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
> 
> Hello,
> 
> On Mon, May 27, 2013 at 01:19:25PM +0300, Pasi Sarolahti wrote:
> > On May 24, 2013, at 10:57 AM, Olivier Bonaventure
> > <Olivier.Bonaventure@uclouvain.be> 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
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm