4 ms·

Thanks for the robust answer. I think the CDN fix could be built right into net-neutrality laws: If you're going to support that functionality then also do it

by and0 10y ago

Thanks for the robust answer. I think the CDN fix could be built right into net-neutrality laws: If you're going to support that functionality then also do it equally to any CDN that is also willing to foot the bill and/or meets certain criteria. For example, don't only let Netflix's smaller competitors let that box sit on your network. (No, this regulation wouldn't be burdensome either.) QoS is something I'm unfamiliar with when it comes to ISPs. I personally wouldn't be offended if some small % of bandwidth was dedicated to services consumers and businesses use that require priority, such as VoIP. As long as that applied to all VoIP services and apps equally, though I'm not sure how you would be able to tell.

JoshTriplett 10y ago
"Apply the same requirements to all services" certainly seems plausible, though that relates more to antitrust than net neutrality. Defining "willing to foot the bill and/or meets certain criteria" would still require very careful drafting to avoid breaking things, though.
wtallis 10y ago
> As long as that applied to all VoIP services and apps equally, though I'm not sure how you would be able to tell. The only fair way to do this is to use port numbers and protocols and endpoint IP addresses only for the purpose of telling which packets belong to which traffic flow or customer. For deciding which flows get priority, you should look only at the actual pattern of traffic: sparse low-rate flows should be assumed to be interactive, in the same manner that your operating system's CPU scheduler assumes that processes with intermittent load are more latency-sensitive than long-running sustained loads. To see how this kind of packet scheduling works in the real world, look at the fq_codel and cake queue disciplines in Linux. The former has become the default for many Linux distributions and is used by some of the more modern commercial wireless routers. This will have the side effect that my ssh session will get the same preferential treatment as your VoIP, unless I'm using it to tunnel rsync.

by and0 10y ago

JoshTriplett 10y ago

"Apply the same requirements to all services" certainly seems plausible, though that relates more to antitrust than net neutrality. Defining "willing to foot the bill and/or meets certain criteria" would still require very careful drafting to avoid breaking things, though.

wtallis 10y ago

> As long as that applied to all VoIP services and apps equally, though I'm not sure how you would be able to tell. The only fair way to do this is to use port numbers and protocols and endpoint IP addresses only for the purpose of telling which packets belong to which traffic flow or customer. For deciding which flows get priority, you should look only at the actual pattern of traffic: sparse low-rate flows should be assumed to be interactive, in the same manner that your operating system's CPU scheduler assumes that processes with intermittent load are more latency-sensitive than long-running sustained loads. To see how this kind of packet scheduling works in the real world, look at the fq_codel and cake queue disciplines in Linux. The former has become the default for many Linux distributions and is used by some of the more modern commercial wireless routers. This will have the side effect that my ssh session will get the same preferential treatment as your VoIP, unless I'm using it to tunnel rsync.