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

Thu May 16 02:23:45 EDT 2024

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

[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? 

[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? 

[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? 

[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? 

[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.) 

[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... 
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? 
> 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. 

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

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

> 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. 
>> 
>> "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 
>> iMessage, mobile: +420775230885
>> Skype: casioa5302ca
>> frantisek.borsik at gmail.com
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
> _______________________________________________
> Nnagain mailing list
> Nnagain at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain