I could webinar with you on our setup if you want an overview.

Many thanks for the distinction between policy and partition; I remember reading about it some time ago in the Heavy Ready DPI report prepared for the CRTC hearing, but had forgotten about it.

I’m not sure about iPoque, but my experience with Packeteer makes classifying individual user streams difficult. This gets into the policy vs. partition type of classification. You use a classification to group a bunch of protocols together (real-time, bulk, etc.) This is the simplest and fastest classification or management scheme. It requires very little overhead on part of the DPI appliance, minimizing delay to processing while keeping overall memory/CPU usage low on the device.

Tracking connections per user (which you would have to do on a agnostic per user basis) requires a per user policy. Every connection is stored in memory for classification. This requires a crap load of CPU and memory on the DPI appliance. More connections and more users and the harder the appliance works to keep up.

This is why I’ve been defending Bell on the way it handled BitTorrent issues. They found (according to the CRTC submission) that BitTorrent traffic in particular was congesting or over subscribing their links. They did exactly what I would have done. Setup a partition (probably a low priority with a rate cap).

Its quick/efficient and gets the job done without overloading equipment. During over subscription periods, the BitTorrent users would have been fighting it out with each other, letting the main channel serve more desirable traffic. As more Torrent users come online they only degrade each others service, not all traffic so people can still e-mail, pay bills, and do “normal” Internet activity.

To clarify what I mean, but ‘heaviest users’ I wasn’t referring to a historical period, but ‘heavy at the time of congestion’. Thus, if you historically only tend to use a very small portion of your bandwidth, but at a moment of congestion happen to be using a significant share of the available bandwidth through that node then you would be throttled. This has the advantage of (likely) impeding the historically heavy bandwidth users on a more regular basis than those who very rarely engage in activity that would generate congestion.

What is certainly an issue is that there is typically a need to distinguish between service types (e.g. Skype versus STMP traffic). This is certainly something that a pure agnostic position would have issues with, though potentially what could instead be done is this: after classifying particular subtypes of traffic (e.g. real-time, bulk, etc) then throttling is applied to a particular subtype of traffic in an agnostic fashion. For example, if P2P is in the ‘bulk’ section (and thus identified as delayable) then not just P2P but ALL protocols in the ‘bulk’ section are throttled. In this sense, it would be protocol agnostic within traffic subtypes.

I generally like iPoque’s whitepapers; the people behind them do good work and engage with issues from a variety of positions and take then seriously. It’s quite nice change from an industry that is typically shrouded in smoke and mirrors *grin*

I think I can answer this for you. When shaping traffic, DPI appliances don’t analyze historical flows. So the back history of a users usage isn’t readily available. Each application of a policy is done nanosecond by nanosecond so a full understanding of the overall bandwidth usage of a user is not available. That would require more caching and analysis than most/all? units currently provide.

Also, traffic managers are usually concerned about the responsiveness of an application. As iPoque pointed out, various applications have different needs (latency/number of connections/overall data transfer rates or some combination of each) that affect an applications serviceability. Which is why priority by application (VOIP followed by streaming TV followed by etc.) is really the best approach. Application agnostic shaping of traffic does no good if all you can hear over your Skype connection is … occasi… word…. fro… the other part…

Allowing latency sensitive applications a higher priority does not usually affect high bandwidth transfers like FTP/HTTP or P2P. They will still get most of the circuit most of the time, they just have to pull over to the slow lane while the high priority VOIP traffic zips through.

I liked that white paper BTW, it echoes many of things I’ve written at my blog. The sign of intelligence is how much someone agrees with you and all that!