From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bobcat.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 631623B29D for ; Sat, 1 Jun 2024 13:39:37 -0400 (EDT) Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by bobcat.rjmcmahon.com (Postfix) with ESMTPSA id 7512C2487E for ; Sat, 1 Jun 2024 10:39:36 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bobcat.rjmcmahon.com 7512C2487E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjmcmahon.com; s=bobcat; t=1717263576; bh=dFs3nXhviixLQjBfxTZd7SCtAM2HEl6EpdfCNLvcnTo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TzLsbPqK14QyMkNpbKRxAbsrtn78tf+YGuc3J9JTTtkJe96KlUtCguXzJeg1tLg/S 95mV6amgIk7/PduSd9OATZ7d6kq4QW31ra9Tvj1kRqhkAG+l75shJdGLxoEEZFMYNy CEGpUXsf8ZIgURTkmTLy7ig5r6PAZhjn5twW3pOg= Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-62c6317d15cso28908677b3.2 for ; Sat, 01 Jun 2024 10:39:36 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWl3YvRKQKq8ZgxggfAdHLyv5H1lXYXIqiybtqJjg49/d0kbtvjs7cmx2hjeHVoqYAxXbt/inbVLq7GS9j+dUA825Su4sqUm/dQtPmbcg== X-Gm-Message-State: AOJu0YzeUPaeT7IZ0QCBpHVgsKTVrv/u2MxgoESKORlq3d3RaiIY1ozO LMaQY7l/M3oeXxQPlKNKLbndosGhLvWJ4rD4xW4gwpn4Nw9329a9RrSB6J746Jsms3bzCtvynmr 6I9xy0bd5x4ZJBhbGIRPZC5OVx04= X-Google-Smtp-Source: AGHT+IEEb61kA9Y9H+u2PFqmXUf5eQf4GlDDpGcHRLilmGqfiLjwoX7/CHN4wIEYRf7UF/LNaq6VVUgvNsdTyPx/+7A= X-Received: by 2002:a81:4ed1:0:b0:617:cb98:f9b2 with SMTP id 00721157ae682-62c79824345mr55917467b3.43.1717263575657; Sat, 01 Jun 2024 10:39:35 -0700 (PDT) MIME-Version: 1.0 References: <26794f65-08a1-403e-a69d-530c6e481cb2@dcrocker.net> In-Reply-To: <26794f65-08a1-403e-a69d-530c6e481cb2@dcrocker.net> From: Robert McMahon Date: Sat, 1 Jun 2024 10:39:24 -0700 X-Gmail-Original-Message-ID: Message-ID: To: dcrocker@bbiw.net, =?UTF-8?Q?Network_Neutrality_is_back=21_Let=C2=B4s_make_the_technical_aspect?= =?UTF-8?Q?s_heard_this_time=21?= Content-Type: multipart/alternative; boundary="00000000000069bca30619d79545" Subject: Re: [NNagain] I keep hoping that we will turn this corner X-BeenThere: nnagain@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: =?utf-8?q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_aspects_heard_this_time!?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2024 17:39:37 -0000 --00000000000069bca30619d79545 Content-Type: text/plain; charset="UTF-8" Queueing theory that I've read doesn't cover modern wireless networks such as 802.11 where the fields and interactions in freespace are very different than fields over a conducted copper wires or waveguides. And where the receiving antennas can change orientation quite easily creating step functions in so-called "network power" (throughput/latency) and where the traffic loads are non linear and likely chaotic. And where the media access is distributed in a way that A doesn't know what B, C, D, ... are doing to the receiver(s). And where network designers assume a packet is a property of nature vs a man made artifact. And where power per bit can no longer be met by AC plugs & leashes but needs a mobile energy source and store. The idea that there is a single optimum or single holy grail queue algorithm for the parameter space seems misguided. My view is the queue depth should be defined by the waveguide which is very hard because end to end is not a single uniform waveguide, rather a lashing together of disparate ones. Networking is hard and we still haven't deployed fronthaul or Fi-Wi networks which is going to take awhile. Bob On Sat, Jun 1, 2024, 8:24 AM Dave Crocker via Nnagain < nnagain@lists.bufferbloat.net> wrote: > On 6/1/2024 7:48 AM, Dave Taht via Nnagain wrote: > > > https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/ > > > A curse of being bright is failing to recognize when we aren't. If only > there were a term for that... > > Some decades back, I heard Kleinrock give a summary of queuing theory > research where he reduced it to a graph. Throughput vs. latency. The > curve was almost flat, rising only slightly, until the knee of the > curve, which was quite sharp, going to almost vertical. He noted that > the math for this was complicated but the summary description was not: > "Things are very, very good, until they are very very bad. When they are > good, you don't need queuing. When they are bad, queuing won't help; > you need more capacity. Queuing is for the brief and occasional period > within the knee of the curve." > > If it ain't transient then queuing isn't the answer. If it is > transient, you don't need lots of buffering. > > Systems thinking is not natural for most of us, and bufferbloat is an > example of local optimization without attention to systems effects. For > the list of push-backs your article cites, that lack of attention is due > to excessive faith in entirely misguided intuitions. > > Systems thinking requires quite a bit of skepticism about intuitions. > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker@mastodon.social > > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain > --00000000000069bca30619d79545 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Queueing theory that I've read doesn't cover mode= rn wireless networks such as 802.11 where the fields and interactions in fr= eespace are very different than fields over a conducted copper wires or wav= eguides. And where the receiving antennas can change orientation quite easi= ly creating step functions in so-called "network power" (throughp= ut/latency) and where the traffic loads are non linear and likely chaotic. = And where the media access is distributed in a way that A doesn't know = what B, C, D, ... are doing to the receiver(s). And where network designers= assume a packet is a property of nature vs a man made artifact. And where = power per bit can no longer be met by AC plugs & leashes but needs a mo= bile energy source and store.=C2=A0

The idea that there is a single optimum or single holy grail queue al= gorithm for the parameter space seems misguided.
My view is the queue depth should be defined by th= e waveguide which is very hard because end to end is not a single uniform w= aveguide, rather a lashing together of disparate ones.

Networking is hard and we still haven't = deployed fronthaul or Fi-Wi networks which is going to take awhile.=C2=A0

Bob

On Sat, Jun 1, 2= 024, 8:24 AM Dave Crocker via Nnagain <nnagain@lists.bufferbl= oat.net> wrote:
On 6/1/2024 = 7:48 AM, Dave Taht via Nnagain wrote:
> https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isn= t-a-problem/
>
A curse of being bright is failing to recognize when we aren't. If only=
there were a term for that...

Some decades back, I heard Kleinrock give a summary of queuing theory
research where he reduced it to a graph.=C2=A0 Throughput vs. latency.=C2= =A0 The
curve was almost flat, rising only slightly, until the knee of the
curve, which was quite sharp, going to almost vertical.=C2=A0 He noted that=
the math for this was complicated but the summary description was not:=C2= =A0
"Things are very, very good, until they are very very bad. When they a= re
good, you don't need queuing.=C2=A0 When they are bad, queuing won'= t help;
you need more capacity.=C2=A0 Queuing is for the brief and occasional perio= d
within the knee of the curve."

If it ain't transient then queuing isn't the answer.=C2=A0 If it is=
transient, you don't need lots of buffering.

Systems thinking is not natural for most of us, and bufferbloat is an
example of local optimization without attention to systems effects.=C2=A0 F= or
the list of push-backs your article cites, that lack of attention is due to excessive faith in entirely misguided intuitions.

Systems thinking requires quite a bit of skepticism about intuitions.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

_______________________________________________
Nnagain mailing list
Nnagain@lists.bufferbloat.net
https://lists.bufferbloat.net/li= stinfo/nnagain
--00000000000069bca30619d79545--