[LibreQoS] [Rpm] [Starlink] net neutrality back in the news

rjmcmahon rjmcmahon at rjmcmahon.com
Thu Sep 28 13:04:57 EDT 2023


Here's is the point for TLDR by Noam. Neutral traffic acceptance is not 
no priorities. We want traffic priorities despite all the b.s. that 
they're unfair.

"All of common carriages free-flow, goals of low transaction cost, and 
no-liability goals are thus preserved by a system of (a) non-exclusive 
interconnection (b) neutral traffic acceptance."

Back to TLDR per Noam. This is the pertinent part. First, few in the 
U.S. want the IAPs to be common carriers. It would really bad.

The following factors are important in determining common carriage:
...
law and regulations define the responsibilities of the parties.

For contract carriers, on the other hand:
...
contracts define parties' responsibilities.

And then, the issue isn't so much about CPE side but peering or 
interconnection of networks.

Interconnectivity is critical to the future network system. Yet 
interconnectivity does not happen by itself; that is the lesson of 
decades of American experience. Open network architecture, comparably 
efficient interconnection, and collocation are part of this evolution.

Such interconnection arrangements do not depend on common carriage, 
though they are inspired by it. Therefore, its is possible,

Then Noam's suggestions on how to go forward to protect common carriage 
principals with contract carriage operators through "neutral" 
interconnections. Notice there is no mandate of equal traffic priority 
only neutral access to the network. Priorities can be negotiated per 
business contracts e.g. peering agreements.

VIII. What for the Future?

...

This suggests that new policy instruments will have to be found to deal 
with the negatives effect on information diversity and flow.

A way to do so is by replacing the principle of common carriage by a new 
principle of neutral interconnection. A carrier can elect to be private 
by running its own self-contained infrastructure, and having full 
control over its content, use and access. But if it interconnects into 
other networks and accepts transmission traffic from them, it cannot 
pick some bits over other bits. This means that while a private carrier 
can be selective in its direct customers, whether they are end-users or 
content providers, it cannot be selective in what it accepts from 
another interconnected carrier.

Among interconnected carriers, no carrier can transmit selectively 
traffic passed on to it by another carrier, based on content, uses, or 
usage, or refuse interconnection on these grounds. Any carrier offering 
interconnection to some carriers must offer it to other carriers, too, 
within technical constraints.

This does not require interconnection on equal terms, as in the case of 
common carriage. But it establishes the possibility of arbitrage if 
differentiated pricing occurs. All of common carriages free-flow, goals 
of low transaction cost, and no-liability goals are thus preserved by a 
system of (a) non-exclusive interconnection (b) neutral traffic 
acceptance.

Bob
> On 9/28/23, 12:45, "Starlink on behalf of Dave Taht via Starlink"
> <starlink-bounces at lists.bufferbloat.net
> <mailto:starlink-bounces at lists.bufferbloat.net> on behalf of
> starlink at lists.bufferbloat.net
> <mailto:starlink at lists.bufferbloat.net>> wrote:
>> It would be nice, if as a (dis)organisation... the bufferbloat team
> could focus on somehow getting both sides of the network neutrality
> debate deeplying understanding the technological problem their
> pre-conceptions face, and the (now readily available and inexpensive)
> solutions that could be deployed, by most ISPs, over a weekend. We are
> regularly bringing up a few thousand people a week on libreqos (that
> we know of), and then of course, there are all the home routers and
> CPE that are increasingly capable of doing the right thing.
> 
> [JL] The FCC will soon (maybe today) open a notice of proposed
> rulemaking - aka NPRM. That process provides an opportunity for anyone
> to file and filings from technical experts are always highly valued.
> 
> 
> 
> 
> _______________________________________________
> Rpm mailing list
> Rpm at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm


More information about the LibreQoS mailing list