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 BBEF63B29D for ; Sun, 1 Oct 2023 15:52:00 -0400 (EDT) Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3ae35773a04so7788119b6e.0 for ; Sun, 01 Oct 2023 12:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696189920; x=1696794720; darn=lists.bufferbloat.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=13F4EQF2bOQJYlWQZD2C6Uqs4Buzzcd34OV07bZILjc=; b=SoVkeKVocwnnczk1WWIgduq2TA7UzKjk6wMINDMJLxARP9qNTAF+c8f4Qpxy4ZE1uM n/JTTtRp4qe4uk6kEZLKAnJJ3qe0YCqByVOaZnUZlDR5tbjY3gmYMdnnUacuGF2wPsj8 oTFUvnxi1LDYK3JfHW0TZi5nFS3jc5F8LiGMsAHqMm1XWdZYpMAZkRU8cq3yCJ/62Cjr p1gUWo8NaQzIwp0hYaFWiyS/5LvXE8fAbktn6TZhs0pHdiE/xRC9nY8IxJlfZkju2TeJ pqDUtL1XVFsOATDJqBIC9Nbj49unGHQItSibv81p5vjogeELz5PeeBqxflAdYO5Ctjdp Dx0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696189920; x=1696794720; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=13F4EQF2bOQJYlWQZD2C6Uqs4Buzzcd34OV07bZILjc=; b=Ffg+zvC2j6b2CrgU3802RCfIOtibgRYAIxXGHVfBMeuwetDwWSsnIPpj59NZkLzo3F dOt7dgmVWAWfc8MwvRpYXfDQqmi7L7nqlAa/Qj90h8QMj5ojEsYxoRwx+C4Lcyy6/zWo BtxOyBj/WtfJl8xQ1lL0gi4lQZRIHGTxb32SEVUJq/08QKn2dLqMCcVyabKgds6DEOAR MsMgfNN7LBiObA6W7G8fSeYnnqZX2KrFn22ZnFKWYMbkSd5a6Z+a84n6GOuSVljPBpRm MsO2qx+2qf0W3/xj9CnBjjGWDH9U3bNwkjsfDgN4xrajs3F9KOEBQ+xBDjYAJ9GMf6sU YXbw== X-Gm-Message-State: AOJu0YzjvlddAP8PVW7p+F0uLVPohasLxVdny2LGRj+TH+IVtNJvvDI+ lLFDU3/Zb4ydhv/9w3FRBrwEbs+ebjWf5RoFvjl6nLe8WUs= X-Google-Smtp-Source: AGHT+IHTzLwuvJOQiWgnAvyv8FH/WDmP3aT+QIl1QpG/3abgsG5QarkXgMnb5EmABl8zYOevx1mkYn7bQo+lMSk52JI= X-Received: by 2002:a05:6808:16a4:b0:3af:983a:8129 with SMTP id bb36-20020a05680816a400b003af983a8129mr70055oib.53.1696189919767; Sun, 01 Oct 2023 12:51:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Sun, 1 Oct 2023 12:51:48 -0700 Message-ID: To: Frantisek Borsik Cc: =?UTF-8?Q?Network_Neutrality_is_back=21_Let=C2=B4s_make_the_technical_asp?= =?UTF-8?Q?ects_heard_this_time=21?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [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 19:52:00 -0000 I kind of expect many, many forks of conversations here, and for those introducing a new topic, I would like to encourage using a relevant subject line, so I have changed this one to suit. On Sun, Oct 1, 2023 at 11:57=E2=80=AFAM Frantisek Borsik wrote: > > OK, so I will bite the bullet! I have invited Ajit Pai and Martin Geddes = to join us here and let's see if they still have some time and/or even stom= ach for current round of NN discussion. 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! > Anyway, here is my bullet. I will argue with Martin, that - Net Neutralit= y CAN'T be implemented: 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. > >> 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= =99s 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 p= articular =E2=80=9Cover the top=E2=80=9D service provider. By coincidence, = the performance of your favoured application drops at the same time your IS= P launches 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 poin= t that the =E2=80=9Cthrottling=E2=80=9D began. A swathe of routes, includin= g the one to your preferred =E2=80=9Cover the top=E2=80=9D application, hav= e been 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 = survive the resulting court case and expert witness scrutiny: > > > https://www.martingeddes.com/one-reason-net-neutrality-cant-implemented/ 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. In part I kind of reject a few older arguments here in the face of subsequent, technical improvements on how the internet works. 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. 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. 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. 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. 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. Instead: 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. > > I hope you will read the link ^^ before jumping to Martin's conclusion, b= ut still, here it is: > >> >> So if not =E2=80=9Cneutrality=E2=80=9D, then what else? This is the phase where his arguments began to fall into the weeds. >> The only option is to focus on the end-to-end service quality. 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. >>The local traffic management is an irrelevance and complete distraction. 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 > Terms like =E2=80=9Cthrottling=E2=80=9D are technically meaningless. The = lawgeneers who have written articles and books saying otherwise are unconsc= iously incompetent at computer science. 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. 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. >> We computer scientists call this viable alternative =E2=80=9Cend-to-end= =E2=80=9D approach a =E2=80=9Cquality floor=E2=80=9D. In googling I have thus far been unable to find a definition of "Quality floor". Cite, please? > The good news is that we now have a practical means to measure it and har= d science to model it. Weeds, here. >> Maybe we should consciously and competently try it? ... if only we had running code and rough consensus. > > > > All the best, > > Frank > > Frantisek (Frank) Borsik > > > > https://www.linkedin.com/in/frantisekborsik > > Signal, Telegram, WhatsApp: +421919416714 > > iMessage, mobile: +420775230885 > > Skype: casioa5302ca > > frantisek.borsik@gmail.com > > > > On Sun, Oct 1, 2023 at 7:15=E2=80=AFPM Dave Taht via Nnagain wrote: >> >> 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). >> >> 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] >> >> I am basically planning to move the enormous discussion from over >> here, titled "network neutrality back in the news": >> >> https://lists.bufferbloat.net/pipermail/starlink/2023-September/thread.h= tml >> >> 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. >> >> 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. >> >> 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. >> >> The third phase was when title ii was rescinded... and all that has >> happened since. >> >> 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. >> >> 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. >> >> So here we "NN-again". Lay your issues out! >> >> >> >> [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. >> >> [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 Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.htm= l Dave T=C3=A4ht CSO, LibreQos