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

[Vint Cerf]

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 at 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 at gmail.com
>
> _______________________________________________
> Nnagain mailing listNnagain at lists.bufferbloat.nethttps://lists.bufferbloat.net/listinfo/nnagain
>
> _______________________________________________
> Nnagain mailing list
> Nnagain at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/nnagain/attachments/20240515/82708e9c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4006 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/nnagain/attachments/20240515/82708e9c/attachment.bin>