Re: [v6ops] Net Neutrality question

[Mikael Abrahamsson <[e-mail]>]

On Thu, 19 Nov 2015, Fred Baker (fred) wrote:

> 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."

>From my experience, this happens for networks where moving bits is 
expensive. I would not use the word "commonly", but it's not "uncommon". 
Same thing with in-line cache boxes, if you're paying 100 USD / month per 
megabit/s then you want to do everything in your power to keep data local 
and keep customer use down, if you pay 0.5 USD / month per megabit/s, then 
you do not care much.

I have seen operators get into trouble when doing this heavy handedly, and 
I think I know operators that do this without customers being much 
impacted (for instance they will use these kinds of boxes to re-encode or 
rate-limit video for customers with monthly data caps, so the video uses 
less bandwidth).

> 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.

Yes, you do not need DPI, some boxes will do traffic analysis and deduct 
that a certain flow is X, and will then apply shaping/rate-limiting to 
this flow.

> 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.

Yes, that could make sense.

> 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.

Yep.

> There's probably something I'm missing. Could someone point it out to 
> me? (please be gentle...)

No, you're on the right track, these boxes I talk about above could 
definitely do this kind of marking. I wouldn't be surprised if some of 
them already do, usually the "action" part can be drop or re-mark.

However, the operator has to be careful to keep the AFnX in the same queue 
so reordering doesn't happen, that might be something good to point out 
because it's not obvious to everybody. Also, equipment that would use AFnX 
for drop probability within the same queue, that's not something I think 
is very commonly available today. I don't remember seeing this myself in 
any equipment I have come across...

-- 
Mikael Abrahamsson    email: [e-mail]