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 PM 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 simply > 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 datagrams > 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 PM 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 effect >> of slowing a sender of packets? Might it preclude a provider "helpfully" >> dropping stale video packets that would arrive at a users video rendering >> 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 used >> 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 means >> of blocking spam from being delivered, would that violate the rules? (Same >> question for blocking of VoIP calls from undesirable sources. 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.) >> >> 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. 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. >> >> --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. >> >> "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 degrade >> lawful Internet traffic on the basis of Internet content, application, or >> service." >> >> >> https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-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.bufferbloat.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.bufferbloat.net/listinfo/nnagain > > > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain >