<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Whatever "the service" is, I wonder what the new rules imply about
how traffic is processed. <br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
Jack Haverty<br>
<br>
<div class="moz-cite-prefix">On 5/15/24 17:55, Vint Cerf via Nnagain
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHxHggeRgjXUdcfd8v1VedQLiiYBDNTY3tagivijazzui07vFQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">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.
<div><br>
</div>
<div>v</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, May 15, 2024 at
5:43 PM Karl Auerbach via Nnagain <<a
href="mailto:nnagain@lists.bufferbloat.net"
moz-do-not-send="true" class="moz-txt-link-freetext">nnagain@lists.bufferbloat.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>As a matter of drafting the FCC has left some potholes:</p>
<p>"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,"</p>
<p>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.)<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p> --karl--<br>
</p>
<div>On 5/10/24 7:31 AM, Frantisek Borsik via Nnagain wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>"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. </div>
<div><br>
</div>
<div>"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. </div>
<div><br>
</div>
<div>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."</div>
<div><br>
</div>
<div><a
href="https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/</a><br>
</div>
<div><br>
</div>
<br clear="all">
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>All the best,</div>
<div><br>
</div>
<div>
<p class="MsoNormal"
style="color:rgb(34,34,34)">Frank</p>
<p class="MsoNormal"
style="color:rgb(34,34,34)">Frantisek
(Frank) Borsik</p>
<p class="MsoNormal"
style="color:rgb(34,34,34)"> </p>
<p class="MsoNormal"
style="color:rgb(34,34,34)"><a
href="https://www.linkedin.com/in/frantisekborsik"
style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.linkedin.com/in/frantisekborsik</a></p>
<p class="MsoNormal"
style="color:rgb(34,34,34)">Signal,
Telegram, WhatsApp: <a
href="tel:+421%20919%20416%20714" value="+421919416714" target="_blank"
moz-do-not-send="true">+421919416714</a> </p>
<p class="MsoNormal"
style="color:rgb(34,34,34)">iMessage,
mobile: <a
href="tel:+420%20775%20230%20885" value="+420775230885" target="_blank"
moz-do-not-send="true">+420775230885</a></p>
<p class="MsoNormal"
style="color:rgb(34,34,34)">Skype:
casioa5302ca</p>
<p class="MsoNormal"
style="color:rgb(34,34,34)"><a
href="mailto:frantisek.borsik@gmail.com" style="color:rgb(17,85,204)"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">frantisek.borsik@gmail.com</a></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Nnagain mailing list
<a href="mailto:Nnagain@lists.bufferbloat.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">Nnagain@lists.bufferbloat.net</a>
<a href="https://lists.bufferbloat.net/listinfo/nnagain" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.bufferbloat.net/listinfo/nnagain</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Nnagain mailing list<br>
<a href="mailto:Nnagain@lists.bufferbloat.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">Nnagain@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/nnagain"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.bufferbloat.net/listinfo/nnagain</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>Please send any postal/overnight deliveries to:</div>
<div>
<div>Vint Cerf</div>
<div>Google, LLC</div>
<div>1900 Reston Metro Plaza, 16th Floor</div>
<div>Reston, VA 20190</div>
<div>+1 (571) 213 1346<br>
</div>
<div><br style="color:rgb(34,34,34)">
</div>
</div>
<div><br>
</div>
<div>until further notice</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Nnagain mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Nnagain@lists.bufferbloat.net">Nnagain@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/nnagain">https://lists.bufferbloat.net/listinfo/nnagain</a>
</pre>
</blockquote>
<br>
</body>
</html>