A DPI, networking and joy of technology blog.

Thursday, August 7, 2008

On Dr. Reeds DPI hearing

Susan Crawford blogged about DPI a few weeks ago*, highlighting something that previously flew below my radar - a testimony by David Reed (MIT) at a US congressional subcommittee. 

While I definitely concede that Dr Reed has a lot more experience in networking than I do, there's a few points I just have to respectfully disagree with. Keep in mind that it's the DPI industry that pays my bills, so I can't really call myself impartial here. FYI.

One thing before we start - this is related to DPI in use by Internet Service Providers, not necessarily DPI as implented by higher education or private enterprises. I believe it's the right of these entities to govern their own traffic, for several reasons (I'll be touching some of that in a later post)

"First, that such technologies are not at all necessary to operating the Internet or to 
profitable operation of an Internet operator..."
"Scaling: To make a faster Internet, all one need do is process the envelopes faster."

This is one of the main tenets. While I do agree with his idea that the success of the net is in part fuelled by the simplicity and standardization of IP (run any app without compatibility issues, forward compatibility, etc), I regularly see networks where it'd be next to impossible to run the network properly without some sort of limitations imposed on the end users. In these cases 'processing the envelopes faster' would require technology not yet in existence - use cases would be rural broadband wireless ISPs in Australia, Wyoming or elsewhere. Another one is mobile data networks. In these cases we have a hard and technical limit. Sure, there'll be technical advances that'll improve the situation - but these ISP's are sometimes the only option for users in rural areas, and it'll be hard to side-step the fact that we're talking about truly shared media here. Service now or maybe theoretically better/fairer service in the future?

"...the Internet Architecture, as defined by the IETF and other 
bodies who oversee the Internet's evolution, neither requires nor allows Internet 
Datagrams to be modified or created by AS's in this manner.
[...]
Thus Deep Packet Inspection goes against the separation of concerns that has been a 
hallmark and generator of the Internet's success."

Here's one I kind of agree with in a way. I think it's quite nasty to go modifying the payload transparently and unbeknowst to the user (Ad insertion รก la Phorm), but this is not an inherent capability or feature in every kit doing DPI out there, and what he's saying is 'DPI does this, hence DPI is evil'. Two cases that are, in my opinion, perfectly valid on technical merit and doesn't make any value assumption what so ever about the data while it's in flight:
  • WiFi where the user isn't allowed to use the Internet before an agreement is accepted or a fee is paid. In this scenario you'd want to block anything that isn't HTTP and direct the HTTP requests to a special login page until the conditions are met. (Yes, you can do this without DPI as well, if you start making assumptions based on ports. Which is daft.)
  • Statistics collection based on protocol and/or application. If you know what's on your network, it's easier to plan for upgrades. It'd also be possible to offer services better tailored to a given set of users. Merely knowing the throughput on a per-user basis does not give any hints about how jitter or latency sensitive the apps are. Sure, the stats from a DPI stat unit gives a hint at best, but a hint is way more than blind guessing (Dr Reed actually touches this later on, saying "Finally, Deep Packet Inspection technologies are used for monitoring the performance and health of Internet operations. [...] Such tools can be quite helpful in finding faults within the network and predicting areas of growth that support AS's"
This is without even touching the cases where it'd - in my opinion - make sense to actually shape data, be it for lowering cost or for making operating a network feasible in the first place.

"Deep Packet Inspection systems work by deliberately interfering with end-to-end communications, but by definition attempt to deceive the endpoint systems about what the original Internet Datagrams contain."

In one word: No. I agree that DPI is a very much battered term (in fact, see one of my previous posts regarding that), but DPI is not inherently equal to modifying data in-flight. Traffic shaping gear, for instance, can (usually) operate in a manner where a given protocol will be given a smaller pipe to operate in - i.e less bandwidth available per user. It's quite possible to debate whether that's kosher or not, but it does not trigger the risks that Mr Reed highlight.

Summarizing a bit: I agree that's it's close to moronic to randomly go modify the contents of packets in-flight, but what Dr Reed is describing is a mere subset of DPI gear. Saying 'DPI is evil' is overly broad.


* Bear with me - since shortpacket.org is brand new, there will be comments on stuff that's not hot off the presses as long as it's interesting.

No comments: