From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 B3C823CB48 for ; Fri, 2 Jul 2021 15:46:18 -0400 (EDT) Received: by mail-wr1-x429.google.com with SMTP id p8so13773763wrr.1 for ; Fri, 02 Jul 2021 12:46:18 -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=w09EUtGgeo5IY0ALeDGih6swxApW8ZMp200ML1VK6Eo=; b=ZOsDHz1mBrCp6fU6AJ3rNPfti1PTt+PGo8VVZ5n2W/b/qf8Ga8RpcjyzKq6k4FcNc6 /i1F7PUENe393DWFMwmcVQpxbiOuFc+XhorXZGPE9+0lsq8LS/w3T2M0SC1y3pjeAFOj 4SvWAnNDKmwqK6XZ1KNDal/j5oMyQLykhqmLguIMuawrglSjXr/DJvNirMDLhOIQvm+e wST57qlX+0ceGwmB/5enkWW4BTgyz3r1em39aTJ47cx0c5i1CkTyS4EpseFrkHcpin1Z 8ikMZ34GOrNckWItSZnkgQnYzCZoP0IDn+Zj71z4ED9aeXQaAwNSBNPANgRi/5thMKF5 Hl7w== 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=w09EUtGgeo5IY0ALeDGih6swxApW8ZMp200ML1VK6Eo=; b=jlgaM1g2Co9fDuiLhiTbytBQRoVaE5Ib9FgtEJXC+tb3/I/t5e5ZSYFlz/h7QmGgRk lMtu7YhAYDqoekN+NX3j5TGvIt03ostzh9aOKFztxAvGoU71JbD2ZRVLqyr41d8Z81RH Z7k4SkA5XuFnCtJz5PTqn/pOki6z8C1sA3Z99/M50PSWIqlenbRixwkX3LfbQVnlCEA2 H1XyAKxkq2Q4a3ZBXvBHLnX9na7PAyUjjzSpcwzhmWjEVC/FJzgC7W8ICjKbDyRc3zfO U/KeQpErSKS1dIIoleckIqAm0uQhNK/YUYZAr9ZJRtzRCEpNeTG8JjwjolMg+kUiTlBD EIhw== X-Gm-Message-State: AOAM531X7p9IKAsh7zpaUVWXxArIY2C9kY3pQwjeEhbuh/hr92kxYxzY L2ciP4KIDyeq2wvgM1iEhLj94lk0i0evEztqzdmfpw== X-Google-Smtp-Source: ABdhPJyQ/otiRh9Zo+iQQnbl3bw1E6LsL1vLuqMdGcn2BPH+SIIcDtur+/fhvrWv/UbdRHf08o/JeNFcAyWd6aX5lMY= X-Received: by 2002:adf:ef8b:: with SMTP id d11mr1400696wro.346.1625255177280; Fri, 02 Jul 2021 12:46:17 -0700 (PDT) MIME-Version: 1.0 References: <55fdf513-9c54-bea9-1f53-fe2c5229d7ba@eggo.org> <871t4as1h9.fsf@toke.dk> <3D32F19B-5DEA-48AD-97E7-D043C4EAEC51@gmail.com> <1465267957.902610235@apps.rackspace.com> <20210702095924.0427b579@hermes.local> In-Reply-To: <20210702095924.0427b579@hermes.local> From: Matt Mathis Date: Fri, 2 Jul 2021 12:46:05 -0700 Message-ID: Subject: Re: [Bloat] Bechtolschiem To: Dave Taht Cc: Jonathan Morton , Stephen Hemminger , David Reed , Ketan Kulkarni , "cerowrt-devel@lists.bufferbloat.net" , bloat Content-Type: multipart/alternative; boundary="00000000000083827305c62935e2" X-List-Received-Date: Fri, 02 Jul 2021 19:46:18 -0000 --00000000000083827305c62935e2 Content-Type: text/plain; charset="UTF-8" The argument is absolutely correct for Reno, CUBIC and all other self-clocked protocols. One of the core assumptions in Jacobson88, was that the clock for the entire system comes from packets draining through the bottleneck queue. In this world, the clock is intrinsically brittle if the buffers are too small. The drain time needs to be a substantial fraction of the RTT. However, we have reached the point where we need to discard that requirement. One of the side points of BBR is that in many environments it is cheaper to burn serving CPU to pace into short queue networks than it is to "right size" the network queues. The fundamental problem with the old way is that in some contexts the buffer memory has to beat Moore's law, because to maintain constant drain time the memory size and BW both have to scale with the link (laser) BW. See the slides I gave at the Stanford Buffer Sizing workshop december 2019: Buffer Sizing: Position Paper Note that we are talking about DC and Internet core. At the edge, BW is low enough where memory is relatively cheap. In some sense BB came about because memory is too cheap in these environments. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay We must not tolerate intolerance; however our response must be carefully measured: too strong would be hypocritical and risks spiraling out of control; too weak risks being mistaken for tacit approval. On Fri, Jul 2, 2021 at 9:59 AM Stephen Hemminger wrote: > On Fri, 2 Jul 2021 09:42:24 -0700 > Dave Taht wrote: > > > "Debunking Bechtolsheim credibly would get a lot of attention to the > > bufferbloat cause, I suspect." - dpreed > > > > "Why Big Data Needs Big Buffer Switches" - > > > http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf > > > > Also, a lot depends on the TCP congestion control algorithm being used. > They are using NewReno which only researchers use in real life. > > Even TCP Cubic has gone through several revisions. In my experience, the > NS-2 models don't correlate well to real world behavior. > > In real world tests, TCP Cubic will consume any buffer it sees at a > congested link. Maybe that is what they mean by capture effect. > > There is also a weird oscillation effect with multiple streams, where one > flow will take the buffer, then see a packet loss and back off, the > other flow will take over the buffer until it sees loss. > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --00000000000083827305c62935e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The argument is absolutely correct for Reno, CUBIC and all= other=C2=A0self-clocked protocols.=C2=A0 One of the core assumptions in Ja= cobson88, was that the clock=C2=A0for the entire system comes from packets = draining through the bottleneck queue.=C2=A0 In this world, the clock is in= trinsically brittle if the buffers=C2=A0are too small.=C2=A0 The drain time= needs to be a substantial fraction of the RTT.

However,= we have reached the point where=C2=A0we need to discard that requirement.= =C2=A0 One of the side points of BBR is that in many environments it is che= aper to burn serving CPU to pace into short queue networks than it is to &q= uot;right size" the network=C2=A0queues.

The = fundamental problem with the old=C2=A0way is that in some contexts the buff= er memory has to beat Moore's law, because to maintain constant drain t= ime the memory=C2=A0size and BW both have to scale with the link (laser) BW= .

See the slides I gave at the=C2=A0Stanford Buffe= r Sizing workshop december 2019:=C2=A0Buffer Sizing: Position Paper=C2=A0

Note that we are talking about DC and Internet core.=C2=A0 At the edg= e, BW is low enough where memory is relatively cheap.=C2=A0 =C2=A0In some s= ense BB came about because memory is too cheap in these environments.
=

Thanks,
--MM--
The best way to predict the futur= e is to create it. =C2=A0- Alan Kay

We must not tolerate intolerance= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response mus= t be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 too strong would be hypocritical and risks spiraling out of control= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being = mistaken for tacit approval.

<= /div>

On Fri, Jul 2, 2021 at 9:59 AM Stephen Hemminger <stephen@networkplumber.org> wrote:
<= /div>
On Fri, 2 Jul 2021 0= 9:42:24 -0700
Dave Taht <dave= .taht@gmail.com> wrote:

> "Debunking Bechtolsheim credibly would get a lot of attention to = the
> bufferbloat cause, I suspect." - dpreed
>
> "Why Big Data Needs Big Buffer Switches" -
> http://www.arista.com= /assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf
>

Also, a lot depends on the TCP congestion control algorithm being used.
They are using NewReno which only researchers use in real life.

Even TCP Cubic has gone through several revisions. In my experience, the NS-2 models don't correlate well to real world behavior.

In real world tests, TCP Cubic will consume any buffer it sees at a
congested link. Maybe that is what they mean by capture effect.

There is also a weird oscillation effect with multiple streams, where one flow will take the buffer, then see a packet loss and back off, the
other flow will take over the buffer until it sees loss.

_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
--00000000000083827305c62935e2--