Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01

[Mark Allman <[e-mail]>]

> I think the non-SACK stuff should be removed and that the use of
> SACK  should be made mandatory.
> 
> First of all, this doesn't matter in practice because everybody (for
> a  large value of "everybody") supports SACK today anyway.

We wondered about this at some point in the past and I don't think we
ever developed consensus that completely cutting to SACK was a good
idea.

Personally, I have no problem with it as SACK is clearly the way to go
and, as you note, it is widely supported.  So, I am personally on-board
if the WG wants us to chop those sections out.  (I do not, however,
speak for my co-authors on this.  I don't recall their hit.)

(We just finished putting together a wide-ranging study of traffic from
DSL customers and found 97% of the connections trying to use SACK (i.e.,
in the SYN) and 82% of the connections ultimately using SACK (i.e., also
in the SYN+ACK).  On a host-level we find 82-94% of the hosts use SACK
(the variation is across datasets and also across host counting
techniques since we cannot simply use IP address or even DSL line-id
because of NATs).)

> Second, allowing people to pick and choose arbitrarily is a bad
> precedent and undermines our work.

(I don't know that I buy this angle, however.)

> I would like to see the fast retransmit threshold be dependent on the
> actually observed reordering, but I don't think that would work in the
> common use case addressed here, were the whole session is over after a
> handful of segments.

Right... this is a pretty constrained case.  See RFC 4653 for a more
general way to address reordering.

allman