[ NNSquad ] Re: Odlyzko: "The delusions of net neutrality"

[Kriss Andsten <kriss@proceranetworks.com>]

On 20 aug 2008, at 01.22, Robb Topolski wrote:

> DPI appliance vendors and service providers haven't behaved  
> responsibly, and the end result has been predictably bad for the 'net.
>
> I can list examples -- from a major ISP that does use DPI to  
> prioritize VOIP (but only their own), to two vendors that spy for  
> advertising, to another ISP that literally intercepts Gnutella  
> searches and returns "no match found" as a response, and etc..

You'll find ISP's prioritizing VoIP by running it in a side channel as  
well (i.e prioritized bandwidth on the line, but well outside your  
normal IP comms), same with TV over IP, mind. It's quite the standard  
for triple play as far as I can tell. Not saying that to renounce your  
claims, mind, just filling in.

The advertising bits, I'm not too keen on myself - at least not for a  
normal consumer ISP and definitely not without very, very clear  
consumer consent. However, if it means optional(!) cheaper/ad- 
supported access and customers well informed about what's happening  
then it could make sense. As mentioned, I could well foresee using it  
myself if it means free wifi hotspots where I happen to be. (I'm not  
at all sure that it would mean totally free hotspots, but if it did,  
it'd be pretty cool). Incidentally, it'd be possible to use a traffic  
management box to separate opt-in users from non-opt-in-users,  
diverting only the traffic from the opt-in ones to the content  
scanning box in the first place, alleviating at least one pretty big  
concern with the ad targeting DPI boxes.

As for intercepting gnutella searches and faking negative responses, I  
don't like that either. I agree that's where DPI is heading into shaky  
territory, when you start meddling with the actual L7 protocols  
(thankfully, it's not really a standard use case, and most traffic  
management DPI boxes doesn't even support that without some sort of  
third party unit or software). That's not to say that there can't be  
gains to be had by doing it - Sandvine is pushing tech for injecting  
local known peer results into BT tracker responses ( http://www.sandvine.com/products/p2p_element.asp 
 - I can in no way vouch for how well this works or doesn't work,  
though) - but yes, risk vs. gains and I definitely agree that second  
guessing the endpoints is dangerous territory.

> I'm really worried.

I can see why. Thinking of a traffic management unit as a swiss army  
knife of networking, you can do pretty neat stuff with it or some  
very, very boneheaded things. Looking at the number of boxes deployed  
out there though, I'd say that if you brought up ten examples of  
actual packet tampering, that'd be a miniscule amount of the total  
install base of traffic management devices. It doesn't make the ten  
cases less nasty, of course - but putting it in perspective, it's a  
very small amount of the installations and you'd probably find more  
cases of horse play not involving DPI.

There's been enough bad PR surrounding this (you'd be quite familiar,  
obviously :-) that I'd guess ISP's would be looking for plain better  
ways of sorting their P2P issues, if any. Blatant tampering tend to  
generate consumer dissent.

> One side effect is that just about every connectivity problem, odd  
> routing, slowness or latency -- cannot rule out DPI.

Mostly agreed, as long as the unit is doing any shaping - it's not  
that uncommon to let a unit sit in a tap, just collecting stats, or  
inline but sitting passive. Routing would be up to the AS' anyhow, so  
it's hard to label it as odd or not odd - but yes, you could find  
yourself getting sent down different BGP paths depending on the  
contents of a given stream. Latency, yes, depending on how shaping is  
implemented and slowness pretty much by design (not limited to DPI  
though, same thing could apply to quite a few units including non-DPI- 
capable traffic management boxes - just to keep the terminology  
somewhat clear. It seems that it's shaping you're having a problem  
with here, not DPI per se)

That said, it's pretty hard to even detect most traffic management DPI  
units, other than by whatever policy they've got loaded.

> An employee for a major VOIP provider has assured me that one ISP  
> adds latency to its packets.

Plain evil. Perfectly doable without DPI as well, though (netblock +  
port + protocol, add latency), so the intent is the nasty part, not  
the tool. (Granted, I could be biased here)

> Many of the behaviors being changed are Layer 2/3/4 behaviors, but  
> none of these are going through the IETF and none are sufficiently  
> disclosed enough or consistent enough to help network application  
> providers ensure interoperability.

There's a few pretty daft options out there, yes - but the standard  
ones are based around adding (minor amounts of) latency or  
artificially limiting the available bandwidth for a given class of  
traffic - both pretty much the same situations that an IP stack would  
need to be capable of handling anyhow. I don't expect the daft  
solutions to see much love or traffic if they do in fact lead to  
issues (the ISP would likely notice before the end users would)

More invasive methods involve the ability to rate limit the number of  
connections per second per host for some L7 protocols, ports or  
whatnot but this is - in every case I've seen - done by blackholing  
the particular stream or sending RST's to the hosts, also pretty  
vanilla stuff for a stack to cope with.

> In the networking perspective, DPI is awesome power, and with great  
> power comes great responsibility.

Word. Spiderman sure knows his networking..

> Instead, I'm seeing great haste -- haste to rush products out to  
> market, haste to beat the competition in feature sets, and haste to  
> turn these on regardless of their appropriateness.

There's definitely a bit of a gold rush surrounding DPI, with new  
vendors announcing products or support for it every month or so - but  
if I'd be as bold as to define a set of core players peddling traffic  
management + DPI (that is to say the same few companies you notice in  
beauty contests again and again and again), they've all been at it for  
quite a while. Quite a few of the new products that hit the market  
only do DPI in the sense of traffic stream identification, either in  
order to grab stats off the network and nothing else, or to provide  
some other card/box/'solution' with identification capabilities, be it  
for firewalling purposes or for shaping purposes.

The cost per subscriber for a traffic management box tends to be  
fairly low and they do get replaced if they misbehave or just don't do  
as good a job as advertised. I'd guess that this ensures that eventual  
bad apples won't keep on living forever, except for in very isolated  
cases.

I'm not a market analyst though, so your mileage may definitely vary.

> I'm a little worried too that the ISPs misunderstand what they've  
> bought into.  They act as if they own the Internet, that it's theirs  
> to 'enhance' or wall off as they see fit. Yet they sign up customers  
> who are asking for access to the Internet -- not "brand x's" version  
> of it.

It's a risk and a possibility at once, agreed. I'd like to think that  
the vast majority of ISPs buying it do sane things with it and use it  
very carefully and in a non-invasive manner to fix specific issues,  
not as a god box to create AOL II.

> Robb Topolski (robb@funchords.com)
> Hillsboro, Oregon USA
> http://www.funchords.com/

Kriss
http://www.shortpacket.org/