Net Neutrality question
Fred Baker (fred <fred@...
2015-11-19 03:53:00 GMT
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...)
v6ops mailing list