From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 313FF3B2A4 for ; Thu, 16 May 2024 02:23:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1715840636; x=1716445436; i=moeller0@gmx.de; bh=dlPkqmzmPaAOIB3wc8XrG062rJblOkOkMbhtOGdsRU0=; h=X-UI-Sender-Class:From:Content-Type:Content-Transfer-Encoding: Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=PK4sKmcvWshtctdwic2xOLg2wtXWhZdbrBJ+KTosG97rvCpkocizUz297xPjhp08 RWv6/qriAVlZQRd95owfebr/KtbQdNuRrlcwtTugYupuGx93sIxvmqkgcdrhGLhPI Fi9gzq6EnCQIMWqobOQwuMXwS1/zbaoRQTlqEIeP36gwvT3RKREgypGotjbY4KwM9 8xtup3aDyVqrK1RvX9kjcGB/9XUU/e50v+zUg7bDrDo7FrEuelXHhgPg2LUp/wfkO 9zWo16Y9CXKvn4ZEMQzRKiLYJRRNj898j4HHQQr2SZJpqJ2WCySZvWOxxgV2+/FhZ Z5Png6AXkt2oVKWeVg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MKsnP-1rqn7h1Q7x-00HuED; Thu, 16 May 2024 08:23:56 +0200 From: Sebastian Moeller Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Date: Thu, 16 May 2024 08:23:45 +0200 References: To: karl@cavebear.com, =?utf-8?Q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_as?= =?utf-8?Q?pects_heard_this_time!?= In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3774.600.62) X-Provags-ID: V03:K1:KZ5ncCHtsF4iyA2SixFOI0WDbZyM8bPx9dQNcNV2u2WFiOx2T9G b8GeRzUacPgL1f4MvNLGxLghhAn/CDGaVKgwq5SogINSerllE8aG2dLcWZbqyl6iKFn8OiI yNKNGgIfa//OHlyGZKuj+vWh0/ReFsejpOmZlz5V6V6iHWQ5FhuwwdBppkIaMeMMyl1qiTc p4IqN5o6RlI4cl0f/gycA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:rIpwqsK8+wg=;hgSRmGj/OERw99qzmjKifURW5Re D9uHPHQhTcZp/ey8JAnYGtB1/V762dtObn/R9JYfXPSm+ARBxxrY/OENUP5HPjEcc1N2wwZjT XciztVWC5zuoFI0rS80UbCrEQhsLZGbhgart1RX1HAzp+09Pdyi2iBfd/wGG1hHXjXqsfokJp zKw36KUp7wZ3pS/LKguRU+/mIPQ6QVmUz+6WWE8BtXDMBEC4C+4m3IrHnketrd3Lz6ed2CmLl +LMEBHN7RHP8t81REsCnUABk1U/r20d/5pMvDwstlDypSfGVHfAjh+fvJLHE446Czbafrj+mU TFYHd4TsDd1xe2qCRZKQIShPspRvzRVZ7tDDp1rAAjHejZq7/rekaar5sQZcxq4HTdFa3Wxeo JBLlJv4C8DqZdd8qPb5y3rzhokBUkyFvJM73J8WwQ4fh79qqqlXScnRh6Df6jSXjS6+5zAceJ uifIObdlwc/4tDZIz9Vz4pxe61u7fXSDdlAQTws4g7nhWqKOMUH6RBQLFBpmAe+Oo3eO6G1OX z9ZZAjc/HiKeFWQJo2rmqI+fuZlt2Ovu33q6Zr2EPB3FvRsj983wYrworSBlCE77ChQI3IJUo 8sSs8B7MKnmOaXdPmS407aAgasMScLEdp76lFXQyTmdO1UH0sCnQ6jFo9r/KlFSgGyDwlJxq1 KFkY8qg03OMt+wo3ro9m3ZTKt2mQK7kNoNym3kDNyMYa3W7VPJ0uHdtJShM08S8tjL6xWPq9f FC3/B88+RTKIK5MQSV461FM5JYEXUOciBbkqE11gkuIemRhiELq6EpTX2WnDnSxfodY41o0pY 6Zh6Gkhz6veNC4MPcMC7D8d4aICXGU3qEhSD0QLJBSiig= Subject: Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole" 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: Thu, 16 May 2024 06:23:59 -0000 Hi Karl, being a lawyer you know how this works, until a court come to an = interpretation all is in some degree of limbo, so if you want = clarification sue somebody to force an interpretation ;) > On 15. May 2024, at 23:43, Karl Auerbach via Nnagain = wrote: >=20 > As a matter of drafting the FCC has left some potholes: > "We clarify that a BIAS [Broadband Internet Access Service] provider's = decision to speed up 'on the basis of Internet content, applications, or = services' would 'impair or degrade' other content, applications, or = services which are not given the same treatment," > That phrase "speed up" is too vague.=20 [SM] I wholeheartedly agree, speed is delta distance/delta time, and is = typically 2/3 of the speed of light in vacuum for almost all internet = access technologies and not really what an ISP sells, they offer = capacity or information rate, not speed. > Does it conflict with active or fair queue management?=20 [SM] No it does not, equitable sharing between entities is a core = principle behind the internet fair queuing is just the consequent = implementation of the IETF's 'do not starve any flow' principle... you = could rather argue that not doing equitable sharing might get you in hot = water. (Sidenote the IMHO best argument for equitable sharing is not = that it is the 'most best' policy but that it is the 'least bad', to = elaborate knowing the relative importance of data packets one can do a = lot better than treating all equal, but lacking that knowledge treating = all equally is what avoids really bad outcomes, and since arbitrary = bottlenecks never will have robust and reliable information about the = relative importance of packets... equitable sharng is the 'good enough' = solution.) > Does it prohibit things that some Ethernet NIC "offloads" do (but = which could be done by a provider) such as TCP data aggregation (i.e. = the merging of lots of small TCP segments into one big one)? [SM] No the relevant TCP stack actions happens on the end points not the = ISP, the ISP's job is to transport the data, if that entails transient = merging and re-segmentation as long as that is opaque to the end user = no. Another thing is ACK filtering where ISPs interfere with customer = data, albeit with the goal to improve the link quality for the customer. > Does it prohibit insertion of an ECN bit that would have the effect of = slowing a sender of packets?=20 [SM] Not really, as alternatively a packet would have been dropped with = even more drastic effects, not only is this a 'slow down' signal but the = dropped packet will need to be retransmitted.... > Might it preclude a provider "helpfully" dropping stale video packets = that would arrive at a users video rendering codec too late to be = useful?=20 [SM] Hard to say, even a late packet might help decoding later packets = versus dropping it, so I would argue not the ISPs business to interfere. > Could there be an issue with selective compression?=20 [SM] Yes, if an ISP recompresses material unasked he better make sure = the compression is completely invisible to the end user, which IMHO = rules out lossy compression schemes. An ISP is in the business of = transporting bits not manipulating bits. > Or, to really get nerdy - given that a lot of traffic uses Ethernet = frames as a model, there can be a non-trivial amount of hidden, usually = unused, bandwidth in that gap between the end of tiny IP packets and the = end of minimum length Ethernet frames. (I've seen that space used for = things like license management.)=20 [SM] The maximal minimum payload size for ethernet is 46 bytes (with = VLAN only 42), an IPv4 header takes 20 bytes, a UDP or TCP header = another 20, so we are down to 6-2 bytes for license management = (controllable ny the user via adding a VLAN tag) that seems a = harebrained idea based on 'nobody is going to look there'. More space = left over with ICMP or ARP...=20 But at least that is novel, all I knew is that the MACs of network cards = have been used for licensing. > Or might this impact larger path issues, such as routing choices, = either dynamic or based on contractual relationships - such as = conversational voice over terrestrial or low-earth-orbit paths while = background file transfers are sent via fat, but large latency paths such = as geo-synch satellite?=20 > If an ISP found a means of blocking spam from being delivered, would = that violate the rules? (Same question for blocking of VoIP calls from = undesirable sources.=20 [SM] That one is easy, if the ISP acts under explicit instruction of the = end user this is A-OK otherwise not. > It may also call into question even the use of IP address blacklists = or reverse path algorithms that block traffic coming from places where = it has no business coming from.) [SM] That is IMHO FUD, BCP38 still applies. That is normal network = hygene... > The answers may be obvious to tech folks here but in the hands of = troublesome lawyers (I'm one of those) these ambiguities could be = elevated to be real headaches. [SM] But a headache you likely will be remunerated well for dealing = with, no? > These may seem like minor or even meaningless nits, but these are the = kinds of things that can be used by lawyers (again, like me) to tie = regulatory bodies into knots, which often a goal of some large = organizations that do not like regulation. [SM] Sure, see above thgis is why this requires court decisions, so = maybe the best to do is bring your own cases to speed up that process? > In addition, I can't put my finger on it, but I am sensing that = without some flexibility the FCC neutrality rules may be creating a kind = of no cost, tragedy of the commons situation.=20 [SM] There is no tragedy of the commons, the commons are known as = "commons" as they operated reasonably successful for a long time, it is = the failure of meaningful policing/regulation of the rules towards their = demise that made the commons fail. So repeat after me (or not), the = tragedy of the commons really is just ineffective regulation and = policing of the rules. We are discovering that the same is true of = market economies, if you let the market players cheat/side step normal = market mechanisms, markets fail to be efficient resource distribution = optimisers.=20 > Sometimes a bit of friction - cost - can be useful to either = incentivize improvements and invention or to make things (like spam) = less desirable/more expensive to abusers. [SM] Indeed, the question is 'is the increase in inconvenience for the = abusers larger than for the normal users', because we might end up in a = situation where all users now have increased friction plus SPAM... Regards Sebastian > --karl-- > On 5/10/24 7:31 AM, Frantisek Borsik via Nnagain wrote: >> "Net neutrality proponents argued that these separate lanes for = different kinds of traffic would degrade performance of traffic that = isn't favored. The final FCC order released yesterday addresses that = complaint.=20 >>=20 >> "We clarify that a BIAS [Broadband Internet Access Service] = provider's decision to speed up 'on the basis of Internet content, = applications, or services' would 'impair or degrade' other content, = applications, or services which are not given the same treatment," the = FCC's final order said.=20 >>=20 >> The "impair or degrade" clarification means that speeding up is = banned because the no-throttling rule says that ISPs "shall not impair = or degrade lawful Internet traffic on the basis of Internet content, = application, or service." >>=20 >> = https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-= lanes-closing-possible-net-neutrality-loophole/ >>=20 >>=20 >> All the best, >>=20 >> Frank >> Frantisek (Frank) Borsik >> =20 >> https://www.linkedin.com/in/frantisekborsik >> Signal, Telegram, WhatsApp: +421919416714=20 >> iMessage, mobile: +420775230885 >> Skype: casioa5302ca >> frantisek.borsik@gmail.com >>=20 >> _______________________________________________ >> Nnagain mailing list >> Nnagain@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/nnagain >>=20 > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain