General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <jch@pps.jussieu.fr>
To: richard <richard@pacdat.net>
Cc: bloat@lists.bufferbloat.net
Subject: [Bloat] Packet drops, ECN and ECN+ [was: Thoughts on Stochastic Fair Blue]
Date: Thu, 24 Mar 2011 23:22:22 +0100	[thread overview]
Message-ID: <7iipv8i2g1.fsf_-_@lanthane.pps.jussieu.fr> (raw)
In-Reply-To: <1300999472.12456.22.camel@amd.pacdat.net> (richard@pacdat.net's message of "Thu, 24 Mar 2011 13:44:32 -0700")

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

  reply	other threads:[~2011-03-24 22:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-13  1:40 [Bloat] Thoughts on Stochastic Fair Blue Jonathan Morton
2011-03-24  1:03 ` Juliusz Chroboczek
2011-03-24  5:30   ` Dave Hart
2011-03-24 20:44     ` richard
2011-03-24 22:22       ` Juliusz Chroboczek [this message]
2011-03-25 19:22         ` [Bloat] Packet drops, ECN and ECN+ [was: Thoughts on Stochastic Fair Blue] Richard Scheffenegger
2011-04-03 16:35       ` [Bloat] Thoughts on Stochastic Fair Blue Juliusz Chroboczek
2011-04-03 18:03         ` Jonathan Morton
2011-03-24 11:59   ` Jim Gettys
2011-03-24 12:40   ` Jonathan Morton
2011-03-24 13:32     ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7iipv8i2g1.fsf_-_@lanthane.pps.jussieu.fr \
    --to=jch@pps.jussieu.fr \
    --cc=bloat@lists.bufferbloat.net \
    --cc=richard@pacdat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox