<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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.</p>
    <p>My concerns arise from a variety of sources.</p>
    <p>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.</p>
    <p>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" - <a class="moz-txt-link-freetext" href="https://www.law.cornell.edu/wex/chevron_deference">https://www.law.cornell.edu/wex/chevron_deference</a> ) 
      Personally, I'd rather that smart people at the FCC figure this
      out rather than a bunch of j-random Congress critters.<br>
    </p>
    <p>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.<br>
    </p>
    <p>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.)</p>
    <p>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 -
      <a class="moz-txt-link-freetext" href="https://www.iwl.com/blog/counting-bits">https://www.iwl.com/blog/counting-bits</a> )  For video that overhead
      is negligible, but for some forms of traffic (e.g. security
      alarms) that overhead can add up.</p>
    <p>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.<br>
    </p>
    <p>        --karl--<br>
    </p>
    <div class="moz-cite-prefix">On 5/15/24 5:55 PM, Vint Cerf 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>
    </blockquote>
  </body>
</html>