Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Mike Conlow <mconlow@cloudflare.com>]

[-- Attachment #1: Type: text/plain, Size: 7181 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 13969 bytes --]