* Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"
2024-05-15 21:43 ` Karl Auerbach
@ 2024-05-15 22:28 ` Robert McMahon
2024-05-16 0:55 ` Vint Cerf
` (2 subsequent siblings)
3 siblings, 0 replies; 12+ messages in thread
From: Robert McMahon @ 2024-05-15 22:28 UTC (permalink / raw)
To: karl,
Network Neutrality is back! Let´s make the technical
aspects heard this time!
[-- Attachment #1: Type: text/plain, Size: 5528 bytes --]
Hmm, seems more about wiglomeration than regulation. Per Dickens,
"Here he is, Esther," said Mr. Jarndyce, comfortably putting his hands into
his pockets and stretching out his legs. "He must have a profession; he
must make some choice for himself. There will be a world more wiglomeration
about it, I suppose, but it must be done."
"More what, guardian?" said I.
"More wiglomeration," said he. "It's the only name I know for the thing. He
is a ward in Chancery, my dear. Kenge and Carboy will have something to say
about it; Master Somebody--a sort of ridiculous sexton, digging graves for
the merits of causes in a back room at the end of Quality Court, Chancery
Lane--will have something to say about it; counsel will have something to
say about it; the Chancellor will have something to say about it; the
satellites will have something to say about it; they will all have to be
handsomely feed, all round, about it; the whole thing will be vastly
ceremonious, wordy, unsatisfactory, and expensive, and I call it, in
general, wiglomeration. How mankind ever came to be afflicted with
wiglomeration, or for whose sins these young people ever fell into a pit of
it, I don't know; so it is."
On Wed, May 15, 2024, 2: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
>
> iMessage, mobile: +420775230885
>
> 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
>
[-- Attachment #2: Type: text/html, Size: 9828 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"
2024-05-15 21:43 ` Karl Auerbach
2024-05-15 22:28 ` Robert McMahon
@ 2024-05-16 0:55 ` Vint Cerf
2024-05-16 1:14 ` Jack Haverty
2024-05-16 1:53 ` Karl Auerbach
2024-05-16 6:23 ` Sebastian Moeller
2024-05-16 13:03 ` Livingood, Jason
3 siblings, 2 replies; 12+ messages in thread
From: Vint Cerf @ 2024-05-16 0:55 UTC (permalink / raw)
To: karl,
Network Neutrality is back! Let´s make the technical
aspects heard this time!
[-- Attachment #1.1: Type: text/plain, Size: 4838 bytes --]
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
[-- Attachment #1.2: Type: text/html, Size: 8934 bytes --]
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4006 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"
2024-05-16 0:55 ` Vint Cerf
@ 2024-05-16 1:14 ` Jack Haverty
2024-05-16 1:45 ` Mike Conlow
2024-05-16 1:53 ` Karl Auerbach
1 sibling, 1 reply; 12+ messages in thread
From: Jack Haverty @ 2024-05-16 1:14 UTC (permalink / raw)
To: nnagain
[-- Attachment #1.1.1.1: Type: text/plain, Size: 6455 bytes --]
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
>> <tel:+421%20919%20416%20714>
>>
>> iMessage, mobile: +420775230885 <tel:+420%20775%20230%20885>
>>
>> Skype: casioa5302ca
>>
>> frantisek.borsik@gmail.com
>>
>>
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://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 list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
[-- Attachment #1.1.1.2: Type: text/html, Size: 13611 bytes --]
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2469 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"
2024-05-16 1:14 ` Jack Haverty
@ 2024-05-16 1:45 ` Mike Conlow
0 siblings, 0 replies; 12+ messages in thread
From: Mike Conlow @ 2024-05-16 1:45 UTC (permalink / raw)
To: Network Neutrality is back! Let´s make the technical
aspects heard this time!
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"
2024-05-16 0:55 ` Vint Cerf
2024-05-16 1:14 ` Jack Haverty
@ 2024-05-16 1:53 ` Karl Auerbach
2024-05-16 13:07 ` Livingood, Jason
1 sibling, 1 reply; 12+ messages in thread
From: Karl Auerbach @ 2024-05-16 1:53 UTC (permalink / raw)
To: Vint Cerf,
Network Neutrality is back! Let´s make the technical
aspects heard this time!
[-- Attachment #1: Type: text/plain, Size: 7887 bytes --]
You are right, a simple expression of the goal is almost certainly a far
better way to express a regulation than an endlessly detailed
enumeration of things.
My concerns arise from a variety of sources.
First is the natural inclination of some large organizations to use
regulatory language as a weapon, often twisting inadequately detailed
expressions of intent around a Procrustean iron bed of regulatory
definitions.
Second is that the US Supreme Court seems to be tending to cast disdain
on the expertise of regulatory bodies, such as the FCC, to find sensible
ways through difficult and ambiguous situations. (This legal stuff tends
to go under the header of "Chevron deference" -
https://www.law.cornell.edu/wex/chevron_deference ) Personally, I'd
rather that smart people at the FCC figure this out rather than a bunch
of j-random Congress critters.
Third is that sometimes it is useful to have a bit of financial or
competitive fire to push innovation or to impede ill use. (Imagine if
sending emails had a cost - that could have [perhaps] have slowed the
rise of spam.) So perhaps a small amount of non-neutrality could act as
a driver or catalyst.
I am intrigued by the possibility of obtaining better efficiency from
the net - by using underused bandwidth (hence my example of the spare
space where a small IP packet does not fully occupy a minimum sized
Ethernet frame.) Some of these ideas could cause streams to piggyback
on one another (such as how SMS messaging kinda piggybacked into the
empty spaces of telco signalling protocols.) We tend to focus our
attention of big fat flows, like entertainment video or gaming, but
there are a lot of small flows that could ride, with adequately
reliability, for essentially no technical cost. These could include a
lot of home, security, or medical monitoring stuff.) This is hard to
articulate - but there are real life analogies, such as the notion of
van-pooling to airports, where a single vehicle carries diverse
loads/passengers that have little relationship to one another except
that they are traveling to and from roughly the same locations.)
A while back I wrote some notes about network measuring tools such as
iperf. One of the things that struck me was the number of bits that
wrap even the smallest of packets. (For instance -
https://www.iwl.com/blog/counting-bits ) For video that overhead is
negligible, but for some forms of traffic (e.g. security alarms) that
overhead can add up.
And yes, I am stepping dangerously close to notions of multiplexing
within packets or at least within one of our most common wrappers for IP
packets, Ethernet frames.
--karl--
On 5/15/24 5:55 PM, Vint Cerf 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
>> <tel:+421%20919%20416%20714>
>>
>> iMessage, mobile: +420775230885 <tel:+420%20775%20230%20885>
>>
>> Skype: casioa5302ca
>>
>> frantisek.borsik@gmail.com
>>
>>
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://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
>
>
>
[-- Attachment #2: Type: text/html, Size: 14994 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"
2024-05-15 21:43 ` Karl Auerbach
2024-05-15 22:28 ` Robert McMahon
2024-05-16 0:55 ` Vint Cerf
@ 2024-05-16 6:23 ` Sebastian Moeller
2024-05-16 13:03 ` Livingood, Jason
3 siblings, 0 replies; 12+ messages in thread
From: Sebastian Moeller @ 2024-05-16 6:23 UTC (permalink / raw)
To: karl,
Network Neutrality is back! Let´s make the technical
aspects heard this time!
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@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@gmail.com
>>
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"
2024-05-15 21:43 ` Karl Auerbach
` (2 preceding siblings ...)
2024-05-16 6:23 ` Sebastian Moeller
@ 2024-05-16 13:03 ` Livingood, Jason
3 siblings, 0 replies; 12+ messages in thread
From: Livingood, Jason @ 2024-05-16 13:03 UTC (permalink / raw)
To: karl,
Network Neutrality is back! Let´s make the technical
aspects heard this time!
[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]
> That phrase "speed up" is too vague. Does it conflict with active or fair queue management?
No, I don’t think so. AQM is widely deployed to tens of millions of homes in the US – I don’t think the FCC’s intent is to ban such an obviously beneficial improvement in the internet. Rather, they are focused on the notion of creating paid-for “fast lanes” – such as where destination X pays ISP A to prioritize their internet content over other internet content, etc.
> 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)?
No
> Does it prohibit insertion of an ECN bit that would have the effect of slowing a sender of packets?
No. The use of ECN as a congestion signal is specified in IETF RFCs, is already deployed, is an improvement on waiting for packet drops, and ECN deployment is growing and is to the benefit of internet users & traffic.
> Might it preclude a provider "helpfully" dropping stale video packets that would arrive at a users video rendering codec too late to be useful?
Maybe – this will fall into whether that is considered reasonable network management (and for example, why in must be done at the network layer rather than by the user’s client).
> 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?
Maybe – could be a reasonable network management decision & it may take a complaint if some party felt disadvantaged - to define what is judged reasonable here.
> 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.)
Could be an issue – we’ll have to see what complaints arise. But likely also falls under the reasonable network management clause, especially if the traffic is not lawful and/or is malicious/abuse. In the past this has been challenging with shared/virtual infrastructure.
JL
[-- Attachment #2: Type: text/html, Size: 4173 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread