General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: David Collier-Brown <davec-b@rogers.com>
To: aqm@ietf.org
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [aqm] adoption call: draft-welzl-ecn-benefits
Date: Fri, 29 Aug 2014 09:52:30 -0400	[thread overview]
Message-ID: <5400859E.6070202@rogers.com> (raw)
In-Reply-To: <16141ccda1c843ab8f03fb5f478db010@hioexcmbx05-prd.hq.netapp.com>

On 08/29/2014 09:16 AM, Scheffenegger, Richard wrote:
> Hi Gorry,
>
>>> Given QUIC includes FEC to hide losses, I guess it is a good example to
>>> consider whether ECN still offers sufficient benefits over and above
>>> just removing losses.
>>>
>> GF: And then, isn't the implication of AQM to significantly increase the
>> number of "losses" unless we use ECN?
>>
>> Indeed, I have the impression we are confusing many on these points -
>> ECN could change the reaction to congestion signal, and FEC (even
>> opportunistic CC-friendly FEC) can also change the way things react to
>> congestion signals.
> I don't think that an AQM's implication is automatically to increase the number of losses; that may happen to specific flows (in particular, unresponsive ones), but for responsive (non-ECN) ones, the expectation would be to de-correlate the losses, and for TCP, to only have around 1 loss per window when necessary - instead of a burst loss of one window and the expensive recovery...
>
> Perhaps it's that perception that also poses an obstacle to AQM deployment, because of the believe that a dynamic but lower mark/drop threshold will cause more losses?

Goodness gracious, from the point of  view of a queuing network, AQM
reduces losses overall, in the process of minimizing delay and keeping
bandwidth use just below the theoretical maximum.

Oversimplifying, we try to keep the buffers empty, so that if we get a
burst we can handle it without losses and without affecting other
communications. We signal via a loss or other indicator if the
non-bursty flow is enough to cause congestion, which keeps the buffers
near-empty and the system uncongested.

Failing to do so fills the buffers without signalling there is
congestion, and induces delay on everyone who's dependant on the buffer.
Not to mention allowing the congestion to go unreported!

It's not a tradeoff discussion: it's arguably one about correctness.

--dave
[Somebody like Neil Gunther could explain the math of this better, but
the behaviour is well-known in the trade, and cordially hated.
Congestion control is superior to admission control, which is what I
often use to prevent the server equivalent of congestive collapse (:-))]



-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain


           reply	other threads:[~2014-08-29 13:52 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <16141ccda1c843ab8f03fb5f478db010@hioexcmbx05-prd.hq.netapp.com>]

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=5400859E.6070202@rogers.com \
    --to=davec-b@rogers.com \
    --cc=aqm@ietf.org \
    --cc=bloat@lists.bufferbloat.net \
    --cc=davecb@spamcop.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