[Bloat] is there no RED at level3?

[Jim Gettys]

On Thu, Jul 31, 2014 at 4:13 PM, Wes Felter <wmf at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20140731/17c74fa2/attachment-0002.html>