Re: [v6ops] Net Neutrality question

["Ray Hunter (v6ops)" <[e-mail]>]

Fred Baker (fred) wrote:
> I am reviewing a paper on Net Neutrality by someone in a developing country. He describes something that I presume is true of the major ISP in his country. It gets me thinking, and I wonder what folks think of the thought.
>
> The comment he makes is that "operators commonly" (by which I think he means his operator) "install DPI equipment watching for certain high volume applications such as file sharing, and block it."
>
> Comcast went through this, using DPI to trap BitTorrent. They got into a scrap with the FCC. There were two outcomes: LEDBAT (BitTorrent now uses a different transport in order to maximize throughput while minimizing latency, loss, and impact on competing traffic) and RFC 6057 (a Cable Network procedure designed to apply a relatively gentle pushback on a top talker so that everyone gets a turn to communicate without having to identify a subscriber or application, or drop traffic).
>
> If the provider in this case is a Cable Modem provider, RFC 6057 seems like a very reasonable alternative to DPI. I'm guessing it's actually DSL.
>
> Hmm, he thinks...
>
> When we wrote Diffserv, at the request of certain network operators, we duplicated the Cascade implementation of Frame Relay in four Diffserv PHBs - the Assured Forwarding Service, RFC 2597. The premise is that a service provider can measure the rate at which traffic arrives from a customer or peer, mark the first<mumble>  BPS packets AFn1, the next<mumble>  BPS packets AFn2, the third<mumble>  BPS packets AFn3, and discard anything above that out of hand. Couple that with an AQM implementation that applies different parameters to the different DSCPs (when a queue builds up, the probability of loss of AFn1 is close to zero, probability of loss of AFn2 is a little higher, and the probability of loss of AFn3 is a lot higher), and senders that exceed their contracts are likely to experience loss first.
>
> It occurs to me that this service could be used in such a network to accomplish a goal similar to RFC 6057, but in a different way. We're not targeting an application, nor are we targeting a specific subscriber or peer. We're targeting any subscriber or peer that exceeds his contract, and only doing so if and when the result is network congestion. We do use loss, but we use it in a way that at least tries to interact with TCP in a gentle way.
>
> There's probably something I'm missing. Could someone point it out to me? (please be gentle...)
Diffserv + WRED works great for applications that:

1) use TCP
2) use a single session per application
3) are subject to a uniform QoS policy

It works great in an environment where there is end to end governance.

The point is that the "bad guys" or torrent download application writers 
only care about their own app: not about the general health of the 
Internet. And there's no effective governance to able to enforce the 
ISP's rules onto subscribers.

So bulk application developers will bypass any mechanism that does not 
limit or penalize the total traffic rate or overall volume/subscriber.
e.g. they'll fire up multiple sessions, or use UDP, or disguise the 
traffic as something else.

That remains true no matter how you perform the measurement and 
throttling, whether it be DPI or diffserv or anything else.

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>