From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 536063B2A4 for ; Wed, 15 May 2024 21:45:54 -0400 (EDT) Received: by mail-vs1-xe34.google.com with SMTP id ada2fe7eead31-47f2f9f2ac8so2564918137.2 for ; Wed, 15 May 2024 18:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1715823953; x=1716428753; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9ibCKSdZ3T25fla6mbNaCIa9QucD9cuMMtX4cDoFbhY=; b=JriZcrP7y7RyMX9pKbc3Su7aXY4t8e8qkytiMQqeI3H8yArYWifvuXxWJiaxfcwVL7 +M4vQaT5ZaLXWjuC+RGKEbNI7eSCGpsU/pGPbcchJmDO6XEcJ1TQ8cLQ1eWWJnYFvSAW mNjLuF4mPlETm1mEteIVN/0dop0itWWFA6SbSfv+z1TIKHxLOGx18Q0ZM6lTqkb3SWXA GG3C1QyN7MhOkHX8H8HaY9UBr1ogR6t09Lt89vsYKOCGZ2Ct1v3kkkcDkIL5QDx8B6/m +UnWdTucnqzjiUDXqTdfdbKVnYhnIQh0rGzLhV2lNQp1/YR53+e20zq8cNJkGZiZewIm RO3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715823953; x=1716428753; h=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=9ibCKSdZ3T25fla6mbNaCIa9QucD9cuMMtX4cDoFbhY=; b=NIgLNv3gB5uI37CtH9P7Zsl/oszefVWN34sFEu1zHuUCQo8eZQ6y8viy3+Qcsh+3Cv e0blmE/l1+Ps+YeyXxMqnHCLhLe1yhs/1UDCbxWzyzbAmSosP+h64Q/DAFyGhXAf6OK8 l3LbQWmJ9z2gKfGIcM/sDgXf5tbW54uyNDCOKI+gsgCmbwVvu8U7I6f6y3IbcXAMUF3E PDqXFgblHUvF7OoO5AK/B0kuA/UwKXVXPUOmeCfHEyWUCb3OQLWM/JNmgJUvQNku8SJF mCpSlJIjvKa/GVN1WJVfLeVE7/PAEBYl1aAgUVRD1NMRM+I53NSCcoxMRrHnjL9QsJOV JLSg== X-Gm-Message-State: AOJu0YyvJS2EnSeHoG9K9FQ4d6cECyHV/T4KWPDCKaFUOGFC8phyFmb8 7pcomBWtF9rJpqqarXIOCcQyXAdS2GyehPNT8UPqe9m+tQ+Ruxm+lbZwHmGUNe7mOW23cMvHVuf vaFD5dfb1dphZacIrcuL24AWX715T2vH2UEAPFQUN0i26EJvW8VI= X-Google-Smtp-Source: AGHT+IFyf/SlhRowtPv+M8Lg4boIa8heLM+9VZmOfSFQaOu0DRpp4yGEG6jmsdjCiO90mURHlxkl7claFD3ZpBkxKqs= X-Received: by 2002:a05:6102:e09:b0:47e:1529:f3ba with SMTP id ada2fe7eead31-48077e5cbefmr17758727137.32.1715823952050; Wed, 15 May 2024 18:45:52 -0700 (PDT) MIME-Version: 1.0 References: <9a465722-bcdf-4410-ae9a-c0a160081eb5@3kitty.org> In-Reply-To: <9a465722-bcdf-4410-ae9a-c0a160081eb5@3kitty.org> From: Mike Conlow Date: Wed, 15 May 2024 21:45:41 -0400 Message-ID: To: =?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: multipart/alternative; boundary="00000000000028e0bc0618886530" 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 01:45:54 -0000 --00000000000028e0bc0618886530 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's important to remember that "reasonable network management" allows a lot of the things being discussed as examples here. Specifically: "As in past Orders, we continue to recognize that in order to optimize > end-user experience, BIAS providers must be permitted to engage in > reasonable network management practices." (para 499) While I don't love the "speed up" language either, it seems clear from my reading that these rules target the case where the ISP intervenes to apply a traffic policy to certain types of traffic that are not open to any application, thereby "throttling" the selected traffic w/r/t any other traffic (and it's not reasonable network management because they're charging the user). On Wed, May 15, 2024 at 9:14=E2=80=AFPM Jack Haverty via Nnagain < nnagain@lists.bufferbloat.net> wrote: > Whatever "the service" is, I wonder what the new rules imply about how > traffic is processed. > > Even 40 years ago, we tried lots of heuristics to improve performance. > One example I remember was treating datagrams differently depending simpl= y > on the size of their content. Putting a minimal-length datagram at the > front of the output queue would slightly "degrade" the service delivered = to > the large datagrams behind it, but it might avoid a retransmission by > delivering an ACK before a retransmission timer ran out. > > If the new rules prohibit such behavior, I suspect a lot of more modern > "smart queue" strategies might be also prohibited, such that all datagram= s > are given the exact same treatment. FIFO may now be the law? > > With circuits in the 80s running <56kb/sec, such scenarios were of real > concern. Today, with "bufferbloat" and such characteristics of the > Internet, the scenarios are different but still exist. > > Jack Haverty > > On 5/15/24 17:55, Vint Cerf via Nnagain wrote: > > An interpretation of the intent might be not so much a prohibition of > various grades of service but that all grades are available on the same > terms to all comers. > > v > > > On Wed, May 15, 2024 at 5:43=E2=80=AFPM Karl Auerbach via Nnagain < > nnagain@lists.bufferbloat.net> wrote: > >> 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. Does it conflict with active or >> fair queue management? 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)? Does it prohibit insertion of an ECN bit that would have the effec= t >> of slowing a sender of packets? Might it preclude a provider "helpfully= " >> dropping stale video packets that would arrive at a users video renderin= g >> codec too late to be useful? Could there be an issue with selective >> compression? 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 use= d >> for things like license management.) 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? If an ISP found a mean= s >> of blocking spam from being delivered, would that violate the rules? (S= ame >> question for blocking of VoIP calls from undesirable sources. It may al= so >> call into question even the use of IP address blacklists or reverse path >> algorithms that block traffic coming from places where it has no busines= s >> coming from.) >> >> 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 elevat= ed >> to be real headaches. >> >> 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. >> >> 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. Sometimes a bit of friction - c= ost >> - can be useful to either incentivize improvements and invention or to m= ake >> things (like spam) less desirable/more expensive to abusers. >> >> --karl-- >> On 5/10/24 7:31 AM, Frantisek Borsik via Nnagain wrote: >> >> "Net neutrality proponents argued that these separate lanes for differen= t >> kinds of traffic would degrade performance of traffic that isn't favored= . >> The final FCC order released yesterday addresses that complaint. >> >> "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. >> >> The "impair or degrade" clarification means that speeding up is banned >> because the no-throttling rule says that ISPs "shall not impair or degra= de >> lawful Internet traffic on the basis of Internet content, application, o= r >> service." >> >> >> https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fas= t-lanes-closing-possible-net-neutrality-loophole/ >> >> >> All the best, >> >> Frank >> >> Frantisek (Frank) Borsik >> >> >> >> https://www.linkedin.com/in/frantisekborsik >> >> Signal, Telegram, WhatsApp: +421919416714 <+421%20919%20416%20714> >> >> iMessage, mobile: +420775230885 <+420%20775%20230%20885> >> >> Skype: casioa5302ca >> >> frantisek.borsik@gmail.com >> >> _______________________________________________ >> Nnagain mailing listNnagain@lists.bufferbloat.nethttps://lists.bufferblo= at.net/listinfo/nnagain >> >> _______________________________________________ >> Nnagain mailing list >> Nnagain@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/nnagain >> > > > -- > Please send any postal/overnight deliveries to: > Vint Cerf > Google, LLC > 1900 Reston Metro Plaza, 16th Floor > Reston, VA 20190 > +1 (571) 213 1346 > > > until further notice > > > > > _______________________________________________ > Nnagain mailing listNnagain@lists.bufferbloat.nethttps://lists.bufferbloa= t.net/listinfo/nnagain > > > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain > --00000000000028e0bc0618886530 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's important to remember that "reasonable netwo= rk management" allows a lot of the things being discussed as examples = here. Specifically:=C2=A0

"As in past Orders, we continue to recognize that in or= der to optimize end-user experience, BIAS providers must be permitted to engage in reasonab= le network management practices." (para 499)

While I don'= ;t love the "speed up" language either, it seems clear from my re= ading that these rules target the case where the ISP intervenes to apply a = traffic policy to certain types of traffic that are not open to any applica= tion, thereby "throttling" the selected traffic w/r/t any other t= raffic (and it's not reasonable network management because they're = charging the user).=C2=A0
=C2=A0

=C2=A0<= /div>

On Wed, May 15, 2024 at 9:14=E2=80=AFPM Jack Haverty via Nnagain <<= a href=3D"mailto:nnagain@lists.bufferbloat.net">nnagain@lists.bufferbloat.n= et> wrote:
=20
An interpretation of the intent might be not so much a prohibition of various grades of service but that all grades are available on the same terms to all comers.=C2=A0

v


On Wed, May 15, 2024 at 5:43=E2=80=AFPM Karl Auerbach via Nnagain <nnagain@lists.bufferbloat.n= et> wrote:

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 basi= s of Internet content, applications, or services' would 'i= mpair or degrade' other content, applications, or services whic= h are not given the same treatment,"

That phrase "speed up" is too vague.=C2=A0 Does it= conflict with active or fair queue management?=C2=A0 Does it prohibit things that some Ethernet NIC "offloads" do (but wh= ich 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)? Does it prohibit insertion of an ECN bit that would have the effect of slowing a sender of packets?=C2=A0 Might it preclude a provider "helpfully" dropping s= tale video packets that would arrive at a users video rendering codec too late to be useful?=C2=A0 Could there be an issue wi= th selective compression?=C2=A0 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.)=C2=A0 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?=C2=A0 If an ISP found a means of blocking spam from being delivered, would that violate the rules?=C2=A0 (Same question for blocking of VoIP calls from undesirable sources.=C2=A0 It may also call into question eve= n the use of IP address blacklists or reverse path algorithms that block traffic coming from places where it has no business coming from.)

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.

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.

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.=C2=A0 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.

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 --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. Th= e final FCC order released yesterday addresses that complaint.=C2=A0

"We clarify that a BIAS [Broadband Internet Acces= s 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," th= e FCC's final order said.=C2=A0

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."



All the best,

Frank

Frantisek (Frank) Borsik

=C2=A0

https://www.linkedin.com/= in/frantisekborsik

Signal, Telegram, WhatsApp: +4219= 19416714=C2=A0

iMessage, mobile: +420775230885=

Skype: casioa5302ca

frantisek.borsik@gmail.com


_______________________________________________
Nnagain mailing list
Nnagain@=
lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain
_______________________________________________
Nnagain mailing list
Nnagain@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnaga= in


--
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice




_______________________________________________
Nnagain mailing list
Nnagain@=
lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain

_______________________________________________
Nnagain mailing list
Nnagain@= lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain
--00000000000028e0bc0618886530--