[giggles_giggles]

This sounds like you are saying that reclassifying ISPs to be regulated under the FCC instead of the FTC would ban traffic shaping.

Obviously not all packets are equal. VOIP is an example of a high priority protocol. BitTorrent is low priority.

Legislating traffic shaping at this level would be absurd. Have I been living in a cave? Are Net Neutrality advocates arguing that it should be illegal for network operators to perform any kind of traffic shaping, even that which would prioritize the traffic for latency sensitive applications?

[wtallis]

> Are Net Neutrality advocates arguing that it should be illegal for network operators to perform any kind of traffic shaping, even that which would prioritize the traffic for latency sensitive applications?

At least some of us NN advocates believe it should be illegal for ISPs to perform the kinds to traffic shaping that explicitly identify and prioritize certain ports or protocols over others. Because that kind of traffic shaping is not really necessary to offer good QoS, and thus there's no reason to continue allowing it.

[giggles_giggles]

> that kind of traffic shaping is not really necessary to offer good QoS

It is nobody on HN's responsibility to educate me on this, but I'd love some good hearty technical reading on this topic, because this is definitely counter-intuitive to me. If anyone has a link to a resource on this topic or feels motivated to type out a technical description of how QoS could work without explicitly identifying and prioritizing certain traffic, I will read it raptly and greatly appreciate the additional education.

[wtallis]

For home routers, there was a major breakthrough in 2012 with the CoDel AQM algorithm, which was paired with a flow queuing system to create fq_codel and later Cake. These systems do not have any rule sets of the form "prioritize port N". fq_codel and Cake do look at port numbers and protocols, but only for the purposes of sorting packets into separate bins for separate network flows. Each bin gets the same set of rules applied to it, so in that sense they are Neutral.

CoDel on its own prevents a high-latency queue of packets from building up, but since it operates on a single FIFO queue is indiscriminate about which packets get dropped when it's time to drop something. fq_codel and Cake will tend to give priority to new or sparse traffic flows, and when they need to drop a packet they will drop from a flow that has a standing queue—on the assumption that those high-bandwidth flows are likely to be less latency/drop sensitive and probably can back off on their transmit rate. So any protocol with VOIP-like traffic patterns will tend to get prioritized enough to have minimal added latency and no packet loss (provided it's using a small share of available bandwidth), and the packet drops/ECN markings will hit the network flows that are behaving like TCP bulk file downloads. These heuristics do imbue fq_codel and Cake with a bias toward certain traffic-handling policies, but it's very analogous to the heuristics used by a typical operating system CPU scheduler, and well-grounded theoretically and empirically.

I said at the beginning "for home routers", because these new AQMs have not yet been incorporated into the kinds of ASICs used for carrier-grade equipment. But anywhere that it is practical to deploy these algorithms, they are easier to configure and offer better performance than the now-obsolete QoS strategies that depend on things like trying to decide whether port 53 should go to the head of the line to speed up DNS queries. These new algorithms have proven that ISPs do not need to buy any equipment to do things like detect and throttle bittorrent traffic in order to prevent it from overwhelming their network. They just need to upgrade their routers and gateways to use good general-purpose traffic management techniques.

[giggles_giggles]

Wow that was an absolutely fascinating read thank you so much!