Re: [Bloat] Taxonomy of various sender-side TCPs

[Jonathan Morton <chromatix99@gmail.com>]

On 11 Mar, 2011, at 8:05 pm, Dave Täht wrote:

>> On the subject of ECN, my impression is that YouTube currently
>> doesn't enable it, but a one-man company I recently downloaded some
>> stuff from does.  I wonder if there's any reliable data on how many
>> of the most popular sites enable ECN if you ask for it.  Personally,
>> I think IPv6 and ECN should probably go together - v6 gear is new or
>> upgraded anyway so there shouldn't be any legacy problems.
> 
> I agree, but lack data. What TCP algorithms are available in the IPv6
> stack on Linux? I know SFB works with both ipv4 and ipv6...

AFAIK, the TCP congestion algorithms are all implemented independently of IP version, so even the exotic ones are available in v6 already.  I don't think they need to look at the addresses or port numbers.

The qdiscs are also relatively protocol-independent in themselves, I think.  Classifiers are mostly what need to examine the addresses and so on.  In particular, I'm pretty sure SFQ works, and that *does* depend on flow identification, so there is no reason why a competent implementation of nRED or SFB wouldn't.

> ECN has been enabled on kernel org for 8+ years.

Which is great, except that ECN is still not universally enabled client-side, so many problems with random ISPs are still masked until someone starts doing something unusual.

More relevantly, what is the situation with Windows (XP/Vista/7), MacOS X, and the prominent mobile OSes (Android, iOS)?  Do they attempt ECN negotiation already?  What happens if they encounter a black hole while doing so?

 - Jonathan