[Ecn-sane] [Flent-users] [bbr-dev] duplicating the BBRv2 tests at iccrg in flent?

[Sebastian Moeller]

Hii Neal,


On April 6, 2019 1:56:06 PM GMT+02:00, Neal Cardwell <ncardwell at google.com> wrote:
>On Fri, Apr 5, 2019 at 12:20 PM Jonathan Morton <chromatix99 at gmail.com>
>wrote:
>
>> > On 5 Apr, 2019, at 6:10 pm, 'Neal Cardwell' via BBR Development <
>> bbr-dev at googlegroups.com> wrote:
>> >
>> > Right. I didn't mean setting the codel target to 242us. Where the
>slide
>> says "Linux codel with ECN ce_threshold at 242us sojourn time" I
>literally
>> mean a Linux machine with a codel qdisc configured as:
>> >
>> >   codel ce_threshold 242us
>>
>> I infer from this that BBR's new ECN support won't work properly with
>> standard CE marking behaviour, only with the sort of signal that
>DCTCP
>> requires.  Is that accurate?
>>
>
>Yes, that's correct. Thus far BBR v2 is targeting only DCTCP/L4S-style
>ECN.

        Out of curiosity, given that BBR intentionally interprets lost packets as a lossy path instead of a signal send by an AQM to slow down, why do think that dctcp style ECN is a good fit? In classic ECN the CE mark is exactly the signal BBR should get to have a higher confidence that ignoring lost packets is acceptable, in dctcp it will take a while to convey the same signal, no?  I wonder if one is willing to change ECN semantics already, by making CELighter weight than a packetdrop, why not also using an explicit signal for emergency brake? I can't help but notice that both dctcp and tcpprague face the same problem, but at least they seem to be willing to take a Paket drop at face value...

Best Regards
        Sebastian


>
>> SCE allows providing that sort of high-fidelity congestion signal
>without
>> losing interoperability with RFC-3168 compliant flows.
>>
>
>Noted, thanks.
>
>neal

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.