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

[Neal Cardwell]

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:

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190408/b8382cc2/attachment.html>