From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D35423B2A4 for ; Mon, 8 Apr 2019 21:33:30 -0400 (EDT) Received: by mail-oi1-x233.google.com with SMTP id v10so12193090oib.1 for ; Mon, 08 Apr 2019 18:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kd3hQ/fBTtbobCfBuXhno392L9ey2rFLqGg4AGwOm+E=; b=CtafVoadK3oQ8k5i3xz0Q/klCn6SQFBNB+urDQ9nhSuwIazdM79WixJ2Dsh7yGYZdP J+dGIRIR6UPF8RqNSn121uAIogOJpe8mB15LaXDri/XgdQuqwJJBO+6atXE+uSsdooWW rW2otp3Jrv/T3guTryCGy0Y/gxq1NHruk/10UzPMonSnO23/O49Z5T61XVI+BdwBkyGl LbF8XQ9dEQfGhkGUqQiuJI4oO+qFBh3EXtNBs4ctdvw/P5j4RYZ70RuW4fQ+GQvp3E3Y s4snqtgNg3+0EcecC9oU3ittFzbYkCOrbQ3vt+7bluHel+lxLh+P2bmgSJ0/bNrePzEy 8G8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kd3hQ/fBTtbobCfBuXhno392L9ey2rFLqGg4AGwOm+E=; b=X34AupX7G+mk3QL0PjqnLfKoD10S5qwHC7o0dIYboXy4BznRjP5peZXNN08PSVGFWu NvMe5XxRF+h+x6DN6QVli8B1EHoGsP5qBL4cno160p8RoFgcI1SRqGPj4SVlSbhXlg5t y+L2VoO5L4PFAPJQV6qk/iRQAuv6rtzOnb+JmL+CMxcHX6dIu1I4XPFZSZcFZoIoWviQ 4Wa2rtzUdSm1Wh5xWjkqua/rfqlQOTSMfW3l/cFwaJx2XwvP0jToAJNTuVrhHNamdit3 o6uDbvxcuejS6+Ov0OOC+Ertu7uG9m81fn98qwtuX3a0ne5G0H45eV+0fmvfFh9T73UK Aing== X-Gm-Message-State: APjAAAUXyR0iRAKrOcBvlFI9uN0lSwxzkMdumf8nORrnX6cPuKESOxdJ BFL3352jNXyg8Bhn2fbTPuEzGyfxrFmZKtvpmQlWRw== X-Google-Smtp-Source: APXvYqw2s4PSTjFVESSVcA68hAn8wbu2fmZao+4KBPlm+tsDjEZugTxaCgQPXbqJpOYuxkTEiGRvptFWa2ImUfrQ2Bo= X-Received: by 2002:aca:5c55:: with SMTP id q82mr18101633oib.95.1554773609888; Mon, 08 Apr 2019 18:33:29 -0700 (PDT) MIME-Version: 1.0 References: <3EDC8EAC-1EB2-4E64-8973-8AE177D8789C@gmail.com> In-Reply-To: From: Neal Cardwell Date: Mon, 8 Apr 2019 21:33:13 -0400 Message-ID: To: Sebastian Moeller Cc: flent-users , Jonathan Morton , BBR Development , ECN-Sane Content-Type: multipart/alternative; boundary="000000000000b9b1af05860ef06a" Subject: Re: [Ecn-sane] [Flent-users] [bbr-dev] duplicating the BBRv2 tests at iccrg in flent? X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 01:33:31 -0000 --000000000000b9b1af05860ef06a Content-Type: text/plain; charset="UTF-8" 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 --000000000000b9b1af05860ef06a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Apr 6, 2019 at 10:38 AM Sebas= tian Moeller <moeller0@gmx.de>= wrote:
Hii Neal= ,


On April 6, 2019 1:56:06 PM GMT+02:00, Neal Cardwell <ncardwell@google.com> wrote:=
>On Fri, Apr 5, 2019 at 12:20 PM Jonathan Morton <chromatix99@gmail.com>
>wrote:
>
>> > On 5 Apr, 2019, at 6:10 pm, 'Neal Cardwell' via BBR D= evelopment <
>> bbr-= dev@googlegroups.com> wrote:
>> >
>> > Right. I didn't mean setting the codel target to 242us. W= here 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:
>> >
>> >=C2=A0 =C2=A0codel ce_threshold 242us
>>
>> I infer from this that BBR's new ECN support won't work pr= operly with
>> standard CE marking behaviour, only with the sort of signal that >DCTCP
>> requires.=C2=A0 Is that accurate?
>>
>
>Yes, that's correct. Thus far BBR v2 is targeting only DCTCP/L4S-st= yle
>ECN.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 E= CN the CE mark is exactly the signal BBR should get to have a higher confid= ence that ignoring lost packets is acceptable, in dctcp it will take a whil= e to convey the same signal, no?=C2=A0 I wonder if one is willing to change= ECN semantics already, by making CELighter weight than a packetdrop, why n= ot 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 th= ey 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 explanatio= n:


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=
=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 [RFC3168]).=C2=A0...
<= br>
best,
neal

--000000000000b9b1af05860ef06a--