Subject: [v6ops] Net Neutrality question

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 19 Nov 2015 03:53:00 +0000

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

---

From: Barry Raveendran Greene <[email-masked]>
Date: Thu, 19 Nov 2015 13:25:00 +0800

> 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 throughp…

Too complicated and the engineers + vendors who give them free consulting don’t the depth of engineering options available. It is easier for a DPI box to be placed into the network thinking that it is going to work. In most cases, it does not work (people find ways around it). Scaling the DPI also becomes a problem. For now, the “magic DPI box” is the quick fix.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Nov 2015 15:02:08 +0900

On Thu, Nov 19, 2015 at 12:53 PM, Fred Baker (fred) <[email-masked]> 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."
>

Wouldn't that practice violate regulations or even laws in a number of
countries?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 19 Nov 2015 07:25:06 +0100 (CET)

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

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

> 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: [email-masked]

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 19 Nov 2015 06:38:18 +0000

> On Nov 19, 2015, at 7:25 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> 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...

It's on Cisco equipment running IOS, and I believe IOS-XR and friends. I'll send you the MQC Configuration if you're interested. I can't speak to anything else.

---

From: Ivan Pepelnjak <[email-masked]>
Date: Thu, 19 Nov 2015 08:44:36 +0200

It’s easy to measure user-generated traffic at ingress interface, but really hard to identify and measure per-user traffic sent from the Internet toward the user, as no router I’ve seen so far enables you to measure and mark traffic per-destination-IP (or prefix) and that’s how some people might be using the DPI boxes.

In other words, I have yet to see something that would give every user (identified by IP address or prefix) a fair share of bandwidth.

Note: please don’t start the NAT-breaks-this-idea discussion. I’m well aware of that ;)

Hope this helps,
Ivan

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Nov 2015 13:12:27 +0000

>From: v6ops [mailto:[email-masked]] On Behalf Of Ivan Pepelnjak
>Sent: Thursday, November 19, 2015 1:45 AM
>To: Fred Baker (fred); IPv6 Operations
>Subject: Re: [v6ops] Net Neutrality question

>It’s easy to measure user-generated traffic at ingress interface, but really hard to identify and measure per-user traffic sent from the Internet toward the user, as no router I’ve seen so far enables you to >measure and mark traffic per-destination-IP (or prefix) and that’s how some people might be using the DPI boxes.

A network access edge router such as the Cisco CMTS (Cable Modem Termination System) router supports STM (Subscriber Traffic Management) via which each subscriber's traffic can be tracked.   Other Cisco access edge routers support STM as well.

Hemant

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 19 Nov 2015 15:32:20 +0200

On 19/11/2015 15:12, Hemant Singh (shemant) wrote:
> A network access edge router such as the Cisco CMTS (Cable Modem
> Termination System) router supports STM (Subscriber Traffic Management)
> via which each subscriber's traffic can be tracked.   Other Cisco access
> edge routers support STM as well.

cmts boxes are generally quite weird and not representative of how IP is
handled on anything other type of access delivery.

Nick

---

From: Mwendwa Kivuva <[email-masked]>
Date: Thu, 19 Nov 2015 17:56:51 +0300

Yes, this kind of violation of net neutrality is very common especially in
regions with weak regulatory frameworks. I've experienced it in my country.
It is very common to see an ISP advertise for "unlimited" Internet service
only to start throttling it when they discover heavy traffic from the end
users.
On Nov 19, 2015 4:32 PM, "Nick Hilliard" <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Nov 2015 15:17:12 +0000

Here is a MQC sample configuration.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/isg/configuration/xe-3s/isg-xe-3s-book/isg-mqc-ip-sess.html#GUID-24165B88-F485-48B1-9BF4-7278A12E4912

Hemant

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 25 Nov 2015 16:28:20 +0100

Fred Baker (fred) wrote:
> 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.
>
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>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 25 Nov 2015 13:35:13 -0500

As Fred pointed out, we also had it in the Cascade switches - the FR
service description required in-order delivery.

Cheers,
Andy

On Thu, Nov 19, 2015 at 1:38 AM, Fred Baker (fred) <[email-masked]> wrote:

> > 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...
>
> It's on Cisco equipment running IOS, and I believe IOS-XR and friends.
> I'll send you the MQC Configuration if you're interested. I can't speak to
> anything else.
>