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

[d@taht.net (Dave Täht)]

Jonathan Morton <chromatix99@gmail.com> writes:

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

So the

echo vegas > /proc/sys/net/ipv4/tcp_congestion_control

knob applies to both v4 and v6?

I have been thinking that we needed per-device TCP/IP algorithms. An
internal interface differs in requirements from an external gateway,
which in turn differs from several different kinds of wireless
interfaces.

>
> The qdiscs are also relatively protocol-independent in themselves, I
> think.  Classifiers are mostly what need to examine the addresses and
> so on.  

Since the state of ipv6 and encapsulated traffic shaping is so poor
(non-existent), I've been working on pulling together a good classifier
in my Cruft repository, when I have time. I hope we can gather more
shaper people together to work on improving matters for
bufferbloat/ECN/advanced shapers in the coming weeks, now that we have
the debloat-testing tree to work against and work ongoing in openwrt.

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

Testing... We really could use a good example tc implementation of SFB
and HTB at minimum to be playing with.

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

Lots O Testing needed... If you haven't already seen the recent MIT
study on ECN, it's here:

http://mirrors.bufferbloat.net/Talks/AIMS2011/bauer-ecn-aims-2011.pdf

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

I've experienced some issues with the Iphone and ECN, but I have so many
other balls/kernels/tools/drivers in the air regarding wireless that I
have not been able to track it down.
>
>  - Jonathan
>

-- 
Dave Taht
http://nex-6.taht.net