<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p>> That phrase "speed up" is too vague. Does it conflict with active or fair queue management?
<br>
<br>
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.
<br>
<br>
> 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)?
<o:p></o:p></p>
<p><span style="font-size:14.0pt">No<o:p></o:p></span></p>
<p>> Does it prohibit insertion of an ECN bit that would have the effect of slowing a sender of packets?
<o:p></o:p></p>
<p><span style="font-size:14.0pt">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.
<o:p></o:p></span></p>
<p>> Might it preclude a provider "helpfully" dropping stale video packets that would arrive at a users video rendering codec too late to be useful?
<o:p></o:p></p>
<p><span style="font-size:14.0pt">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).<o:p></o:p></span></p>
<p>> 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? <o:p></o:p></p>
<p><span style="font-size:14.0pt">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.<o:p></o:p></span></p>
<p>> 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.)<o:p></o:p></p>
<p><span style="font-size:14.0pt">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.<o:p></o:p></span></p>
<p><span style="font-size:14.0pt">JL<o:p></o:p></span></p>
</div>
</body>
</html>