Network Neutrality is back! Let´s make the technical aspects heard this time!
 help / color / mirror / Atom feed
From: Colin_Higbie <CHigbie1@Higbie.name>
To: "Network Neutrality is back! Let´s make the technical aspects
	heard this time!" <nnagain@lists.bufferbloat.net>
Subject: Re: [NNagain] On "Throttling" behaviors
Date: Mon, 2 Oct 2023 20:34:47 +0000	[thread overview]
Message-ID: <MN2PR16MB3391536B8E04CF494A0CDA29F1C5A@MN2PR16MB3391.namprd16.prod.outlook.com> (raw)
In-Reply-To: <0a158308-e0c1-4722-8013-745e3ded232d@app.fastmail.com>

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

While product and service innovation often originates from pure R&D or work performed in academic labs, in virtually all cases, converting that into commercially viable products and services is the result of profit incentives. A company won’t invest in doing something new with attendant risks unless they can expect a return on that investment greater than the alternatives (or they believe it will provide strategic support to some other product or service). For that reason, we want to be extremely careful about regulating how companies can implement innovations, including the use of potentially distasteful business practices. None of us who want to see the Internet become better over time and more accessible should want anything resembling NN regulation.

The regulatory side of this is largely not a technical discussion because future innovation, by definition, may exceed technical considerations we can conceive of today.

It's easy to conceive of examples where an ISP wants to prioritize or penalize certain kinds of traffic. And while that may seem superficially bad, it’s an important part of the very competition that drives innovation and cost reductions over time. E.g., recall when Google Fiber had been willing to install Gbps fiber in places at a time when most of the rest of the country was struggling to get 20Mbps connections. If Google had wanted to limit that to Google services, that still might have been a boon to those customers. Further, it could have shown the uses and values of what was then considered limitless bandwidth for a home or small business user. Even though this would clearly have been in violation of the tenets of NN, it would have provided important data that might have spawned significant investment by others and advanced the state of connectivity across the board.

I know the counter argument to this is that local ISP monopolies already break innovation, and those companies, especially the big cable companies, therefore have no incentive to provide a good service. I largely agree with that (there is still some small incentive, in that if they are too terrible, customer outcry will turn to voter outcry and demand breaking those monopolies, and they don’t want to risk that).

Therefore, the legal issue to address is NOT how they treat or prioritize data, whether by content or protocol – which they should be allowed to do, EVEN WHEN IT’S BAD FOR CUSTOMERS – but, at least referring to the U.S. specifically with our federal/state system, to put federal limits on durations of regional monopoly durations. I believe this is within the scope of what FCC can mandate (some would debate this and it may take the courts to sort it out). These need not be purely # of years, they can be a function of time to recoup deployment costs. If a company negotiated a local monopoly as part of covering their deployment costs, I would personally say that they should be given an opportunity to recoup those, but then after that, they need to open up their lines for use by competing firms, similar to what happened with the RBOCs and the old telephone lines.

This is also the legal logic behind patents: give a company a 20 year monopoly on the invention in exchange for making it public to everyone and showing them how to do it (the patent must provide clear instructions). We deem the temporary monopoly worthwhile to incent the innovation, provided the inventor makes it public. This is the right philosophy to consider for something like bandwidth innovation, investment, and access.

In short, with ISP’s the open-ended government protected monopolies are the problem, not the providers’ ability to overcharge customers or prioritize some data over others. Competition will fix that over time, as long as competition is allowed to occur. And while it may be faster to force it through regulation, that has dangerous long-term consequences with respect to future innovation.

Starlink is one example of innovation. FTTH is another. Cellular-based Internet is another. Simply buying bulk access on existing lines and repackaging it under different terms could be yet another. Those all seem obvious, because they’re the ones we know. The real danger in unforeseen consequences is the dampening effect NN-style regulations have on yet-to-be-seen innovations, the innovations that never come to fruition because of the regulations.

Cheers,
Colin Higbie


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

  reply	other threads:[~2023-10-02 20:34 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-01 17:15 [NNagain] Some backstory on the nn-again mailing list Dave Taht
2023-10-01 18:56 ` Frantisek Borsik
2023-10-01 19:51   ` [NNagain] On "Throttling" behaviors Dave Taht
2023-10-01 20:50     ` Dave Cohen
2023-10-01 22:01       ` Patrick Maupin
2023-10-02  1:34         ` dan
2023-10-02  7:28           ` Sebastian Moeller
2023-10-02 16:29             ` dan
2023-10-04  7:30               ` Sebastian Moeller
2023-10-02 15:30           ` Andy Ringsmuth
2023-10-02 18:28             ` Nathan Loofbourrow
2023-10-02 20:34               ` Colin_Higbie [this message]
2023-10-02 21:04                 ` Dave Cohen
2023-10-02 21:07                 ` rjmcmahon
2023-10-02 21:43                   ` Colin_Higbie
2023-10-02 21:55                     ` rjmcmahon
2023-10-03 19:29                       ` Colin_Higbie
2023-10-03 19:45                         ` rjmcmahon
2023-10-04  0:57                     ` David Lang
2023-10-03  7:50                 ` Sebastian Moeller
2023-10-03  8:10                   ` Karl Auerbach
2023-10-03 14:41                     ` Sebastian Moeller
2023-10-03 15:34                   ` dan
2023-10-03 16:54                   ` rjmcmahon
2023-10-03 17:55                     ` Sebastian Moeller
2023-10-03 18:09                       ` Frantisek Borsik
2023-10-03 18:14                         ` dan
2023-10-03 19:44                         ` Dick Roy
2023-10-03 18:10                       ` dan
2023-10-03 19:23                         ` rjmcmahon
2023-10-04  1:05                         ` David Lang
2023-10-04  0:39                       ` David Lang
2023-10-03 20:26                   ` Colin_Higbie
2023-10-03 21:40                     ` dan
2023-10-04 15:56                       ` Colin_Higbie
2023-10-04 17:45                         ` David Lang
2023-10-05 20:24                           ` Livingood, Jason
2023-10-05 22:17                             ` Dick Roy
2023-10-05 22:47                               ` Jeremy Austin
2023-10-05 22:53                               ` Dave Cohen
2023-10-06 15:56                                 ` Dick Roy
2023-10-06 15:58                                 ` rjmcmahon
2023-10-04 17:59                         ` rjmcmahon
2023-10-04 19:26                         ` Dick Roy
     [not found]                       ` <MN2PR16MB3391A66B0DC222C43664DAD6F1CBA@MN2PR16MB3391.namprd16.prod.outlook.com>
2023-10-05  8:44                         ` Sebastian Moeller
2023-10-05 19:07                           ` David Lang
2023-10-03 23:17                     ` Mark Steckel
2023-10-04  7:51                       ` Sebastian Moeller
2023-10-02  6:48         ` Sebastian Moeller
2023-10-02 13:43         ` Livingood, Jason
2023-10-02 14:51           ` Mark Steckel
2023-10-02 18:09             ` Livingood, Jason
2023-10-02 18:15               ` Patrick Maupin
2023-10-02 19:18               ` Dick Roy
2023-10-02  6:34     ` Sebastian Moeller
2023-10-02 13:27     ` Livingood, Jason
2023-10-02  6:06   ` [NNagain] Some backstory on the nn-again mailing list Sebastian Moeller
2023-10-02 12:36 ` Bless, Roland (TM)
2023-10-03  7:15   ` Sebastian Moeller
2023-10-02 20:18 [NNagain] On "Throttling" behaviors Livingood, Jason
2023-10-02 20:28 ` Dick Roy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/nnagain.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MN2PR16MB3391536B8E04CF494A0CDA29F1C5A@MN2PR16MB3391.namprd16.prod.outlook.com \
    --to=chigbie1@higbie.name \
    --cc=nnagain@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox