On Sat, Apr 6, 2019 at 10:38 AM Sebastian Moeller wrote: > Hii Neal, > > > On April 6, 2019 1:56:06 PM GMT+02:00, Neal Cardwell > wrote: > >On Fri, Apr 5, 2019 at 12:20 PM Jonathan Morton > >wrote: > > > >> > On 5 Apr, 2019, at 6:10 pm, 'Neal Cardwell' via BBR Development < > >> bbr-dev@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 . Rationale 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 ]). ... best, neal