Re:FCC weakens net neutrality rule in a prelude to larger ro...
by chris_va on Saturday February 25, 2017 @02:32PM
(#13733333)
I think you slightly misunderstood the hypothetical (well, I stated it poorly). In this case, the network is congested and we need to drop packets from a low tier. In the low tier, 90% of the packets are (hypothetically) video streaming. It doesn't need to drop 90% of the packets, I'm just characterizing the traffic in that tier. This is also fairly representative of evening traffic in the US from a residential ISP.
The ISP cannot fully rely on all parties behaving well, unfortunately. The question is: Can the ISP drop packets from this low priced tier that it knows are likely video streaming, even well behaved video streaming, over other packets? Is that acceptable, or "legalized extortion"?
Obviously it would selectively drop DOS traffic first, as you mentioned, but we are past that point.
Re:FCC weakens net neutrality rule in a prelude to larger ro...
by wtallis on Saturday February 25, 2017 @05:12PM
(#13734164)
> The question is: Can the ISP drop packets from this low priced tier that it knows are likely video streaming, even well behaved video streaming, over other packets?
Such a policy is not necessary for the ISP to deliver good quality of service. Content-neutral traffic management is good enough, and often better than poorly-designed discriminatory traffic management policies. There's no real upside to permitting ISPs to engage in this kind of discrimination.
But setting aside the question of whether anybody would sign up for such a shitty ISP, you don't suddenly need to throw out 90% of a customer's traffic unless you're suddenly hit by a DDoS that you can't mitigate in any saner fashion. Congestion that bad will build gradually, and you'll have plenty of RTTs to send congestion signals to your customers. If a customer is running an application that is so unresponsive to congestion signals that they end up using 10x the bandwidth your backhaul has available for them, then that customer can have no reasonable expectation that any other applications remain usable. Any sane video streaming service would have lowered the resolution and then dropped the connection entirely as the congestion developed and packet loss increased.
Ignoring even that, you still haven't come up with a situation that requires non-neutral traffic management. AQMs like Stochastic Fair BLUE and Cake will automatically identify the unresponsive flow(s) and probabilistically drop those packets at whatever rate is necessary to alleviate the congestion, converging on 100% drop probability as the flow continues to behave like a DoS, while well-behaved TCP-like flows are minimally impacted (aside from a degree of congestion signalling necessary to keep their total bandwidth usage within the limit of what's available). SFB and Cake don't care about where the traffic is going other than to identify what flow it belongs to. They don't care what kind of traffic it is, they just care about how it behaves. They're neutral algorithms, and they provide a reasonable solution to the unreasonable challenge you've posed.