NNSquad - Network Neutrality Squad

NNSquad Home Page

NNSquad Mailing List Information


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

Kriss http://www.shortpacket.org/