From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) (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 433363B29D for ; Sun, 1 Oct 2023 16:51:00 -0400 (EDT) Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-5a24b03e22eso22275217b3.0 for ; Sun, 01 Oct 2023 13:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696193459; x=1696798259; darn=lists.bufferbloat.net; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=A9lBe70RLXRNL8sZ+idcAVZfag/kcyzksPlUIl1HwME=; b=BDZwTq1y2J0UBuHVJvfpdjZKDjerukVe2c/Q0uh8qHCoIg7qT1g4OzV2l2ONzl20Pt yDeeu7rB+7sz6RKVt4wqA48pt6qT4qx03ZCq3YFvUkZ3YhmJYwP7Whktx0VmI1Pd17i7 /XwEL0Jl4tQJ4AwjUrkJsEFgYXOoQd3QsL2UBN7xwqIFYXqe7cNejT3nrceOfQHkgLFc N9kYJ2TsGNfBjdCVLgJp8MOTOumqhPYzN9aVjy8kx6oLD71lsXoladLGKN11vRDNwexK yDLCvm+Xf7oMLOJsnG1kifVmMi6QgvC74HSzlO/4gOSNZJk6ETozggOg8bppJHE/jrAg yIQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696193459; x=1696798259; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=A9lBe70RLXRNL8sZ+idcAVZfag/kcyzksPlUIl1HwME=; b=aSMJuHoZgjXjUVETqIs0QsTt75HIS5r+JgjYFLarAPod8XYBqffRmrLdwvmv07NYYz 6SWPOOo7jO2ZbYkDLF4zCk/TvvNFbbFqlyVgwi3nKyx5l0LlL5RL25PTMiSUzqkAQUUn iQ2jJhbV/P8ZMQyrraQ8N3bNEyhfQc2BkdbxcMqeNTlmV0SxhVQ7TupU0va349RiOMjS UiZh3+MRkkANx+1C37dZQTE6xYEGYORI4TzOgYWZ0/wLVht2YJjbpadAzbKWVEht+byG bQLBBzmphBl80wWzhycPxKCdTg8epuYjX3vfH8tNliSSSidcifLTvn65aP1bGXdPvt0l LsmQ== X-Gm-Message-State: AOJu0YynhPbykYe1kEm/w2GQza1Zay3KDcz1aAuxvSHebTmat6V1FJGW eU6+RBKMW0KjpIzNd9sTcNS1bL29QU8dzg== X-Google-Smtp-Source: AGHT+IHB/7Xij0bezGJNWarTwQQyRtN4kkPvf29TwnTycGaDM0yVir7qw/1FVECIFjFtwI1PwyK1Kw== X-Received: by 2002:a81:5d04:0:b0:59a:e88a:750b with SMTP id r4-20020a815d04000000b0059ae88a750bmr10184627ywb.44.1696193459263; Sun, 01 Oct 2023 13:50:59 -0700 (PDT) Received: from smtpclient.apple ([2600:1700:2c58:d080:7c9e:ed5e:b1a:9859]) by smtp.gmail.com with ESMTPSA id l8-20020a0de208000000b00586108dd8f5sm7282423ywe.18.2023.10.01.13.50.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Oct 2023 13:50:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Dave Cohen Mime-Version: 1.0 (1.0) Date: Sun, 1 Oct 2023 16:50:47 -0400 Message-Id: References: In-Reply-To: To: =?utf-8?Q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_techni?= =?utf-8?Q?cal_aspects_heard_this_time!?= X-Mailer: iPhone Mail (20G81) Subject: Re: [NNagain] On "Throttling" behaviors 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: Sun, 01 Oct 2023 20:51:00 -0000 It=E2=80=99s useful for us to remember here that, politics aside, =E2=80=9Cn= eutrality=E2=80=9D is framed by the experience of end users, not by the expe= rience of operators. While much of Martin=E2=80=99s argument that malicious t= reatment and incapable design cannot often be distinguished from one another= is correct, I believe it to be beside the point; from the perspective of mo= st end users, =E2=80=9CI can=E2=80=99t watch Netflix because Comcast is thro= ttling it=E2=80=9D and =E2=80=9CI can=E2=80=99t watch Netflix because Comcas= t doesn=E2=80=99t have enough capacity where Netflix traffic ingresses=E2=80= =9D may be distinguishable arguments but they=E2=80=99re also equally egregi= ous. (With apologies to Jason, Comcast was my home ISP during that era of NN= debates, so my specific argument here is reflexive.) Most users will be sym= pathetic enough to tolerate an occasional service hiccup but will not tolera= te repeated issues, regardless of the cause of those issues or their persona= l ability to differentiate between those causes.=20 Of course this is a two way street. Anyone inclined to believe that large co= mpanies are going to conspiratorially behave maliciously took a big giant vi= ctory lap when Cogent press released that they had successfully throttled Ne= tflix traffic in a controlled experiment, when of course that commanded no s= uch thing.=20 I recall getting into a Twitter fight with Martin around this time on that p= oint. My argument was effectively that end user perception wasn=E2=80=99t go= ing to change and an ISP trying to nuance its way through how it presents it= s traffic management (in effect, the =E2=80=9CQuality Floor=E2=80=9D framewo= rk) was missing the point with its customers; throwing more bandwidth at the= problem was the only way out. I=E2=80=99d like to think that time has prove= n my perspective correct, although the growth in utilization of CDN and edge= networking topologies also subverted the need for bandwidth growth, at leas= t over the public Internet, to be quite so rapid.=20 Dave Cohen craetdave@gmail.com > On Oct 1, 2023, at 3:52 PM, Dave Taht via Nnagain wrote: >=20 > =EF=BB=BFI kind of expect many, many forks of conversations here, and for t= hose > introducing a new topic, > I would like to encourage using a relevant subject line, so I have > changed this one to suit. >=20 >> On Sun, Oct 1, 2023 at 11:57=E2=80=AFAM Frantisek Borsik >> wrote: >>=20 >> OK, so I will bite the bullet! I have invited Ajit Pai and Martin Geddes t= o join us here and let's see if they still have some time and/or even stomac= h for current round of NN discussion. >=20 > Honestly I was hoping for some time to setup, and even perhaps, have > enough of us here > to agree on one of the definitions of NN, to start with! >=20 >> Anyway, here is my bullet. I will argue with Martin, that - Net Neutralit= y CAN'T be implemented: >=20 > You meant "argue along with" rather than "with". I know you are not a > native english speaker, but in the way you said it, it meant you were > arguing against what he described. >=20 >>=20 >>> Whilst people argue over the virtues of net neutrality as a regulatory p= olicy, computer science tells us regulatory implementation is a fool=E2=80=99= s errand. >>> Suppose for a moment that you are the victim of a wicked ISP that engage= s in disallowed =E2=80=9Cthrottling=E2=80=9D under a =E2=80=9Cneutral=E2=80=9D= regime for Internet access. You like to access streaming media from a parti= cular =E2=80=9Cover the top=E2=80=9D service provider. By coincidence, the p= erformance of your favoured application drops at the same time your ISP laun= ches a rival content service of its own. >>> You then complain to the regulator, who investigates. She finds that you= r ISP did indeed change their traffic management settings right at the point= that the =E2=80=9Cthrottling=E2=80=9D began. A swathe of routes, including t= he one to your preferred =E2=80=9Cover the top=E2=80=9D application, have be= en given a different packet scheduling and routing treatment. >>> It seems like an open-and-shut case of =E2=80=9Cthrottling=E2=80=9D resu= lting in a disallowed =E2=80=9Cneutrality violation=E2=80=9D. Or is it? >>> Here=E2=80=99s why the regulator=E2=80=99s enforcement order will never s= urvive the resulting court case and expert witness scrutiny: >>=20 >>=20 >> https://www.martingeddes.com/one-reason-net-neutrality-cant-implemented/ >=20 > Throttling, using DPI or other methods, is indeed feasible. It is very > straightforward to limit flows to or from a given set of IP addresses. > However, there are also technical limitations, based on for example, > the underlying connectivity of a path be it one gbit or 10, which > would also show a customer problem in unwinding the difference between > intentionally throttling and merely being out of bandwidth across that > link. A lot of the netflix controversy was generated because netflix > suddenly ate far far more bandwidth that anyone had provisioned, and > was ultimately addressed by them developing and making easily > available a caching architecture that could be located within an ISPs > borders, saving an enormous amount on transit costs. The rest of the > computing universe followed with enormous numbers of CDNs from the > bigger services being built out in the years following. >=20 > In part I kind of reject a few older arguments here in the face of > subsequent, technical improvements on how the internet works. >=20 > I had many discussions with martin back in the day. The reasoning in > this piece is pretty sound, except that "fairness" can be achieved via > various means (notably flow (fair) queueing), and it has always been a > (imperfectly implemented) goal of our e2e congestion control > algorithms to ultimately converge to a equal amount of bandwidth at > differing RTTs to different services. >=20 > My principal kvetch with his work was that every blog entry during > this period making these points then ended up linking to a "Quality > Floor", called "delta-something", a mathematical method that was > ill-documented, not available as open source and impossible, for me, > at least to understand. The link to that solution is broken in that > link, for example. That quasi-mystical jump to "the solution", I was > never able to make. >=20 > I believe something like this method lives on in Domos=C2=B4s work today, > and despite them filing an internet draft on the subject ( > https://datatracker.ietf.org/doc/draft-olden-ippm-qoo/ ) I remain > mostly in the dark, without being able to evaluate their methods > against tools I already understand. >=20 > I like the idea of what I think a "quality floor" might provide, which > is something that fq-everywhere can provide, and no known e2e > congestion control can guarantee. >=20 > I would like it if instead of ISPs selling "up to X bandwidth" they > sold a minimum guarantee of at least Y bandwidth, which is easier to > reason and provision for, but harder to sell. >=20 > Instead: >=20 > In the last 14 years I focused on restoring correct behavior of the > well-defined congestion controls of the internet, first documented > here: https://ee.lbl.gov/papers/congavoid.pdf and built on the > decades since, while many others made enormous advances on what was > possible - packet pacing, for example, is a genuine breakthrough in > how multiple services from multiple providers can leave sufficient > space for other flows to co-exist and eventually use up their fair > share. >=20 >>=20 >> I hope you will read the link ^^ before jumping to Martin's conclusion, b= ut still, here it is: >>=20 >>>=20 >>> So if not =E2=80=9Cneutrality=E2=80=9D, then what else? >=20 > This is the phase where his arguments began to fall into the weeds. >=20 >>> The only option is to focus on the end-to-end service quality. >=20 > I agree that achieving quality on various good metrics, especially > under load, is needed. The popular MOS metric for voip could use some > improvement, and we lack any coherent framework for measuring > videoconferencing well. >=20 >>> The local traffic management is an irrelevance and complete distraction.= >=20 > I am not sure how to tie this to the rest of the argument. The local > traffic management can be as simple as short buffers, or inordinately > complex, as you will find complex organisations internally trying to > balance the needs for throughput and latency, and for example, the > CAKE qdisc not only does active queue management, and FQ, but > optionally allows additional means of differentiation for > voice/videoconferencing, best effort, and "bulk" traffic, in an > effort, ultimately to balance goals to achieve the "service quality" > the user desires. Then there are the side-effects of various layer 2 > protocols - wifi tends to be batchy, 5G tends towards being hugely > bufferbloated - PON has a 250us lower limit, cable >=20 >> Terms like =E2=80=9Cthrottling=E2=80=9D are technically meaningless. The l= awgeneers who have written articles and books saying otherwise are unconscio= usly incompetent at computer science. >=20 > There are use cases, both good and bad, for "throttling". It is and > has always been technically feasible to rate limit flows from anyone > to anyone. Advisable, sometimes! DDOS attacks are one case where > throttling is needed. >=20 > Breaking the user perception of being intentionally throttled vs the > fate of the the rest of the network would be a goodness. The side > effects of one service, living on a slow network, becoming suddenly > popular, is known as the "slashdot effect", and is mostly mediated by > leveraging CDN and cloud technologies, and totally out of the control > of the local ISP. >=20 >>> We computer scientists call this viable alternative =E2=80=9Cend-to-end=E2= =80=9D approach a =E2=80=9Cquality floor=E2=80=9D. >=20 > In googling I have thus far been unable to find a definition of > "Quality floor". Cite, please? >=20 >> The good news is that we now have a practical means to measure it and har= d science to model it. >=20 > Weeds, here. >=20 >>> Maybe we should consciously and competently try it? >=20 > ... if only we had running code and rough consensus. >=20 >>=20 >>=20 >>=20 >> All the best, >>=20 >> Frank >>=20 >> Frantisek (Frank) Borsik >>=20 >>=20 >>=20 >> https://www.linkedin.com/in/frantisekborsik >>=20 >> Signal, Telegram, WhatsApp: +421919416714 >>=20 >> iMessage, mobile: +420775230885 >>=20 >> Skype: casioa5302ca >>=20 >> frantisek.borsik@gmail.com >>=20 >>=20 >>=20 >>> On Sun, Oct 1, 2023 at 7:15=E2=80=AFPM Dave Taht via Nnagain wrote: >>>=20 >>> I am pleased to see over 100 people have signed up for this list >>> already. I am not really planning on "activating" this list until >>> tuesday or so, after a few more people I have reached out to sign up >>> (or not). >>>=20 >>> I would like y=C2=B4all to seek out people with differing opinions and >>> background, in the hope that one day, we can shed more light than heat >>> about the science and technologies that "govern" the internet, to >>> those that wish to regulate it. In the short term, I would like enough >>> of us to agree on an open letter, or NPRM filing,and to put out a >>> press release(s), in the hope that this time, the nn and title ii >>> discussion is more about real, than imagined, internet issues. [1] >>>=20 >>> I am basically planning to move the enormous discussion from over >>> here, titled "network neutrality back in the news": >>>=20 >>> https://lists.bufferbloat.net/pipermail/starlink/2023-September/thread.h= tml >>>=20 >>> to here. I expect that we are going to be doing this discussion for a >>> long time, and many more issues besides my short term ones will be >>> discussed. I hope that we can cleanly isolate technical issues from >>> political ones, in particular, and remain civil, and factual, and >>> avoid hyperbole. >>>=20 >>> Since the FCC announcement of a proposed NPRM as of Oct 19th... my own >>> initial impetus was to establish why the NN debate first started in >>> 2005, and the conflict between the legal idea of "common carriage" vs >>> what the internet was actually capable of in mixing voip and >>> bittorrent, in >>> "The Bufferbloat vs Bittorrent vs Voip" phase. Jim Gettys, myself, and >>> Jason Livinggood have weighed in on their stories on linkedin, >>> twitter, and elsewhere. >>>=20 >>> There was a second phase, somewhat triggered by netflix, that Jonathan >>> Morton summarized in that thread, ending in the first establishment of >>> some title ii rules in 2015. >>>=20 >>> The third phase was when title ii was rescinded... and all that has >>> happened since. >>>=20 >>> I, for one, am fiercely proud about how our tech community rose to >>> meet the challenge of covid, and how, for example, videoconferencing >>> mostly just worked for so many, after a postage stamp sized start in >>> 2012[2]. The oh-too-faint-praise for that magnificent effort from >>> higher levels rankles me greatly, but I will try to get it under >>> control. >>>=20 >>> And this fourth phase, opening in a few weeks, is more, I think about >>> privacy and power than all the other phases, and harmonization with EU >>> legislation, perhaps. What is on the table for the industry and >>> internet is presently unknown. >>>=20 >>> So here we "NN-again". Lay your issues out! >>>=20 >>>=20 >>>=20 >>> [1] I have only had one fight with the FCC. Won it handily: >>> https://www.computerworld.com/article/2993112/vint-cerf-and-260-experts-= give-fcc-a-plan-to-secure-wi-fi-routers.html >>> In this case this is not so much a fight, I hope, but a collaborative >>> effort towards a better, faster, lower latency, and more secure, >>> internet for everyone. >>>=20 >>> [2] https://archive.org/details/video1_20191129 >>> -- >>> Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.= html >>> Dave T=C3=A4ht CSO, LibreQos >>> _______________________________________________ >>> Nnagain mailing list >>> Nnagain@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/nnagain >=20 >=20 >=20 > --=20 > Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.ht= ml > Dave T=C3=A4ht CSO, LibreQos > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain