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

[Sebastian Moeller]

Hi Neal,

On April 9, 2019 3:33:13 AM GMT+02:00, Neal Cardwell <ncardwell at google.com> wrote:
>On Sat, Apr 6, 2019 at 10:38 AM Sebastian Moeller <moeller0 at gmx.de>
>wrote:
>
>> 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...
>>
>
>I think the L4S team has done a nice job of outlining the problems with
>RFC-3168-style ECN, so I will just quote their explanation:

I guess I was too subtle.... The following is in no way incompatible with what I wrote. The point I wanted to make is that redefining CE without also introducing an equivalent of 'stop hard, ASAP' is an incomplete solution. Once you introduce the missing signal the SCE proposal is a better fit than L4S.
Also both BBR and L4S both aim at basically ignoring drops as immediate signals, both for good reasons like better throughput on links with spurious drops and some reordering tolerance. 
IMHO it is wonderfully absurd in that light to try to basically shoehorn a dctcp style CE-marker into the internet, which does not allow to carry as quickly a stop hard signal as tcp-friendly ECN does today. To repeat the argument is not against finer-grained load information from the bottleneck, but rather against doing only half the job and falling short of solving the problem.
The rationale below would maybe make sense if all the internet's bottlenecks would talk dctcp style ECN, but until then the rationale falls apart.

Best Regards

>
>https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-01#section-5.1
>
>5
><https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-01#section-5>.
>Rationale
>5.1
><https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-01#section-5.1>.
>Why These Primary Components?
>
>   Explicit congestion signalling (protocol):  Explicit congestion
>     signalling is a key part of the L4S approach.  In contrast, use of
>     drop as a congestion signal creates a tension because drop is both
>      a useful signal (more would reduce delay) and an impairment (less
>     would reduce delay).  Explicit congestion signals can be used many
>      times per round trip, to keep tight control, without any
>      impairment.  Under heavy load, even more explicit signals can be
>     applied so the queue can be kept short whatever the load.  Whereas
>      state-of-the-art AQMs have to introduce very high packet drop at
>      high load to keep the queue short.  Further, TCP's sawtooth
>      reduction can be smaller, and therefore return to the operating
>      point more often, without worrying that this causes more signals
>     (one at the top of each smaller sawtooth).  The consequent smaller
>      amplitude sawteeth fit between a very shallow marking threshold
>      and an empty queue, so delay variation can be very low, without
>      risk of under-utilization.
>
>      All the above makes it clear that explicit congestion signalling
>      is only advantageous for latency if it does not have to be
>      considered 'the same as' drop (as required with Classic ECN
>
>        [RFC3168 <https://tools.ietf.org/html/rfc3168>]). ...
>
>best,
>neal

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