Wednesday, September 8, 2010

Lightreading: Cisco's GGSN DPI Feature Under Test [Continued]

    
LightReading published the 2nd part of its Cisco mobile solution testing. See my post on the first part - here.

This time the Cisco GGSN, ASR 5000, (former Starent product) was tested, including its DPI capabilities.

See "Results: ASR 5000 GGSN Performance With DPI" - here.

LightReading summarizes: "In a GGSN role, the Cisco ASR 5000, configured with a Cisco-selected list of 900 HTTP, 99 TCP/UDP stateful filter rules plus one BitTorrent filter rule, achieved the exact same 20 Gbit/s throughput performance with 1 million active subscribers as in the previous GGSN test"

LightReading assumes that "The question in DPI tests is mainly how many rules are there, of what kind, and to what detail" - I must add to that that the rate of new connections (which means the rate of application identification processes) is also an important factor to the DPI performance.

The test itself had one rule for P2P traffic (detecting BitTorrent) and 900 rules for URL match (which Starent had for long time, for charging purposes). All the rest, including VoIP, was detected using layer 3-4 parameters (i.e. non-DPI detection).

If I am trying to correlate the test to common use-cases, my observations are:
  • Use case 1 Slowdown traffic - penalize subscribers that have exceeded their monthly usage limits, or reduce load on congested links - Usually means slowing-down all P2P file sharing traffic not just BitTorrent. Although all they had to do here was to define the relvant policies.
     
  • Use case 2 Block competitive VoIP services - Skype is the major detection challenge - but it was not tested.
     
  • Use case 3  charging - detecting access to a list of URL represents this well. It was tested here (although without the north-bound reporting).
Therefore, I believe that the test (which only tested the DPI process, without the QoS actions that are usually associated with DPI policies) does not really represent the common uses of DPI in mobile broadband environment.

I am also not sure that "Carriers favor integrated solutions, however, for ease of management and maintenance" - for the case of the GGSN, which is the most significant network element in the packet core where stability and performance are above all. It seems that the DPI solution from the pure players are much more advanced in their application identification capabilities.

LightReading comments on the above that "As a side note, the ASR 5000 product documentation (version 10.0) lists support for detection of over 64 peer-to-peer and streaming protocols, including the classics (BitTorrent, eDonkey, Gnutella), voice over IP protocols (Skype, Google Talk, Skinny), games (for example World of Warcraft, Xbox, SecondLife), video streaming (Slingbox etc.), and chat protocols (Fring, Yahoo, MSN...). The operator can not only block the traffic, but also police the bandwidth (limiting VoIP quality to be worse than operator voice service quality, for example – hard to pinpoint for subscribers). We tested only BitTorrent blocking in the available time."


No comments:

Post a Comment