From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 7ABD33CB36 for ; Tue, 9 Apr 2019 10:34:13 -0400 (EDT) Received: by mail-ot1-x334.google.com with SMTP id m10so15764458otp.2 for ; Tue, 09 Apr 2019 07:34:13 -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=3Pk9qV5b5gRH9Y9gW35Cm86gLt2WqWHXRl9VTF4vK2E=; b=mOPCvD+xqVSovzNQU95c+sdN8JFRSEy8ocslGELMc+ztitlzRLH7+dxcMOIHk1rhRv x2WOmTNGdXpT6a1tkydMuAhLVM5K/XxokaKgYFsWTFCFgTIB40b/ya+aAWSJ874oyP1k Lss7oV2Ggi8Si8Ixr+Z0LdLUfy0tzjiEbthD9fGrxghEIMcFiHxf60Ib3zRE8+fqQ+MP 3303Ney//EnDNGYgR8JYStbdztZeqpDaZbtVZBlXaQ1dSQdCsstjRU5/eRmxYV7uP/s7 4OvTtfy3W/5oRZXmX+aMbaA7kMBcFMeT9N2pP4axhG7kbT1+Er9x/l0vA4c1woT+JiZz 5c9w== 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=3Pk9qV5b5gRH9Y9gW35Cm86gLt2WqWHXRl9VTF4vK2E=; b=MKfp39ES75TLquu3H0ElE8+3RHIXaoVppERdB8jJLs706cyMok+zK/TkBWpoFqgbWj T98JURYWPtBN7Ng0WvfiXk9NkRwL7C9RkCyr8m5Sdp8bm5pBt8He1OGHPgDLc4jucaIi GV15D5eggWHKFEEpAVGMpoGKvgsNiFzUzY74f4xQtry2pvKQ9+zGZAnrf44hGrIULxBF ms466b8Bw3T+o/0Qzp7kt05eiN+JJ2hcZA24Xy5Qk2cl1DGD/ALcLQwbEZKk4+GYzUdY A+NpEviIkyoOyi8IuLHs4LI206gWHXVX2ECZCJI7HzJ5kMrhOvi0AIe1Mb8YGIfjmblF a0Rw== X-Gm-Message-State: APjAAAWWNnFkEDCMtlt3TvV1qIP1I1H6oC54z8nK4T9+iMSrr/RSgwRN RaY+iCm0t1OICTHu4bG/XPhOkQLdUo7ZuEVBQ3dwgg== X-Google-Smtp-Source: APXvYqzivCJr2rKJIc0olL3EYQp/TqUi1PvbuDjloQJoM3PaSPYjp1j2qTQflpyT664oazIyi11580G1Vjzx1wJRPWU= X-Received: by 2002:a9d:dc4:: with SMTP id 62mr24180996ots.211.1554820452580; Tue, 09 Apr 2019 07:34:12 -0700 (PDT) MIME-Version: 1.0 References: <3EDC8EAC-1EB2-4E64-8973-8AE177D8789C@gmail.com> <29981DF0-B15C-4A74-82F1-F3929F7DE66E@gmx.de> In-Reply-To: <29981DF0-B15C-4A74-82F1-F3929F7DE66E@gmx.de> From: Neal Cardwell Date: Tue, 9 Apr 2019 10:33:55 -0400 Message-ID: To: Sebastian Moeller Cc: flent-users , Jonathan Morton , BBR Development , ECN-Sane Content-Type: multipart/alternative; boundary="000000000000c48e95058619d803" 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 14:34:13 -0000 --000000000000c48e95058619d803 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 9, 2019 at 2:31 AM Sebastian Moeller wrote: > > 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. OK, I think I now understand what you are suggesting. I can see the potential value of having both a DCGCP/L4S/SCE-style signal and a RFC3168-style signal. In your previous e-mail I thought you were arguing for a pure RFC3168-style approach; but if the proposal is to have both styles, and that's what gets deployed, that sounds usable AFAICT. neal --000000000000c48e95058619d803 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 9, 2019 at 2:31 AM Sebastian = Moeller <moeller0@gmx.de> wrot= e:

I guess I was too subtle.... The following is in no way incompatible with w= hat I wrote. The point I wanted to make is that redefining CE without also = introducing an equivalent of 'stop hard, ASAP' is an incomplete sol= ution. Once you introduce the missing signal the SCE proposal is a better f= it than L4S.
Also both BBR and L4S both aim at basically ignoring drops as immediate sig= nals, both for good reasons like better throughput on links with spurious d= rops 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 q= uickly a stop hard signal as tcp-friendly ECN does today. To repeat the arg= ument is not against finer-grained load information from the bottleneck, bu= t rather against doing only half the job and falling short of solving the p= roblem.
The rationale below would maybe make sense if all the internet's bottle= necks would talk dctcp style ECN, but until then the rationale falls apart.=

OK, I think I now understand what you are = suggesting. I can see the potential value of having both a DCGCP/L4S/SCE-st= yle signal and a RFC3168-style signal. In your previous e-mail I thought yo= u were arguing for a pure=C2=A0RFC3168-style approach; but if the proposal = is to have both styles, and that's what gets deployed, that sounds usab= le AFAICT.

neal

--000000000000c48e95058619d803--