From: Jim Gettys <jg@freedesktop.org>
To: Wes Felter <wmf@felter.org>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] is there no RED at level3?
Date: Thu, 31 Jul 2014 16:44:15 -0400 [thread overview]
Message-ID: <CAGhGL2DB7ZWdnZHtW99zRiGj-uiFZS16ZAD2J2njxiFXiMPUDQ@mail.gmail.com> (raw)
In-Reply-To: <lre816$uk5$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
On Thu, Jul 31, 2014 at 4:13 PM, Wes Felter <wmf@felter.org> wrote:
> On 7/30/14, 5:49 PM, Dave Taht wrote:
>
>> I have been following the level3 vs verizon debate with some interest,
>> trying to sort out fact from fiction. It does appear that once they
>> saturate a core interconnect they end up with nearly 100ms of latency in
>> it. Is RED not available on 10GigE interconnects or any other mediation
>> means to increase packet loss in exchange for getting better latency?
>>
>
> Wasn't CoDel created because nobody understands how to configure RED?
>
More or less.... Dave Oran noted at one IETF meeting that RED tuning (at
least on Cisco gear) might not even be stable between different versions of
their operating system.
CoDel's goal was to be a "do no harm" aqm safe enough to always have turned
on (according to Kathie and Van).
But RED mistuned can hurt you (or so I gather).... And testing your tuning
under load is not something you want to do, even if you can arrange it.
>
> If you've built a network under the assumption that congestion won't
> happen, why enable RED?
>
Backhoe events, tsunamis, and peering disputes show that congestion does
happen. And it takes time to lay more fiber, particularly in backbone
networks. Crystal ball gazing goes only so far on avoiding congestion in
the core. But see above...
>
> If you're in an adversarial public pissing match, is your incentive to
> make the situation look better or worse?
It's commonplace, and given RED's difficulty, hardly surprising to me that
many peering points run without it.
Also note that the *actual* bottleneck may not even be in a device where
you have (W)RED present; switches are widespread...
- Jim
>
>
> --
> Wes Felter
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
[-- Attachment #2: Type: text/html, Size: 3910 bytes --]
prev parent reply other threads:[~2014-07-31 20:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 22:49 Dave Taht
2014-07-31 20:13 ` Wes Felter
2014-07-31 20:44 ` Jim Gettys [this message]
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=CAGhGL2DB7ZWdnZHtW99zRiGj-uiFZS16ZAD2J2njxiFXiMPUDQ@mail.gmail.com \
--to=jg@freedesktop.org \
--cc=bloat@lists.bufferbloat.net \
--cc=wmf@felter.org \
/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