[Bloat] Packet drops, ECN and ECN+ [was: Thoughts on Stochastic Fair Blue]

[Richard Scheffenegger]

IIRC, the IBM AIX5L TCP stack actually sets ECT0 for all TCP segments (pure 
ACK, SYN, SYNACK) when ECN is enabled, not only data segments...

----- Original Message ----- 
From: "Juliusz Chroboczek" <jch at pps.jussieu.fr>
To: "richard" <richard at pacdat.net>
Cc: <bloat at lists.bufferbloat.net>
Sent: Thursday, March 24, 2011 11:22 PM
Subject: [Bloat] Packet drops,ECN and ECN+ [was: Thoughts on Stochastic Fair 
Blue]


>>>> [1] Aleksandar Kuzmanovic. The power of explicit congestion
>>>>    notification. In Proceedings of the 2005 conference on Applications,
>>>>    technologies, architectures, and protocols for computer
>>>>    communications. 2005.
>
>>> http://www.cs.northwestern.edu/~akuzma/doc/ecn.pdf
>>>
>>> appears to be the paper Juliusz cited.
>
> Indeed.  See Figure 3, where you clearly see TCP's admission issues in
> the presence of ECN.  Compare to Figure 2, where dropping at high
> congestion levels works around the issue (mostly).  The authors of the
> paper suggest ECN marking SYN packets ("ECN+") to overcome this issue;
> my reading of their data is that dropping at high congestion levels is
> a good workaround.
>
> (And in case you wonder why the Wikipedia page on ECN agrees with me --
> I wrote it.)
>
>>> I haven't had time to read the paper thoroughly, but I don't argue
>>> with this - if the marking probability goes above 1/2 then you
>>> probably have an unresponsive flow anyway.
>
> Hmm... for TCP, a mark/drop rate of 1/2 means that the fair share is
> slightly less than one packet per RTT, right?  While not very good,
> that's quite likely to happen in The Real World, especially for low RTT
> and browsers opening multiple connections per page.
>
> (And yes, as far as I can see, transitioning to a low-latency Internet
> will require increasing mark/drop rates dramatically.  I'll let you draw
> your own conclusions about whether we can fight bufferbloat without ECN.)
>
>> If nothing else, I take away from this paper that ECN should be applied
>> (at least) on servers (and they advocate clients and routers) to TCP
>> control packets (e.g. SYN and ACK packets) as well as data packets
>> despite the potential (accepted admin legend???) that this might be a
>> "bad thing" for reasons of aiding a potential SYN-flood attack vector.
>
> Unfortunately, other issues have been found with "ECN+" since the paper
> was published, which is why it is no longer being proposed for deployment
> on the Public Internet.  It's been a couple years since I've looked at
> that stuff, though, so it might take me some work to find the reference.
>
> --Juliusz
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat