DPI or Flow Management

Francois Menard francois at menards.ca
Sun Mar 1 17:14:20 UTC 2009


---------- see the small change in the third sentence ---- apologies.

If by french, you actually are wondering if the time could be afforded  
to translate all of the filing to french, and file in both languages,  
the answer is unfortunately no.

However, I most certainly assist with any requested translation.

My take on this is that there is no difference in a peering router  
ignoring DSCP bits, and queuing all of the traffic in the same lane,  
such as to disregard the intended prioritization between the peering  
parties AND FLOW management...

DPI gear instead of ignoring DSCP bits, compute DSCP bits from the  
content of the packer (so-called application headers).

I agree with various party submissions that the 5-layer Internet model  
does not provide for such a concept of headers, which DPI and ILECs  
and Incumbent Cable Operators, call application headers.

I believe that anything traffic management, which purports to place  
its hook on application headers, is by definition, violating network  
neutrality.

However, traffic management in the form of 'pacing packets' based on  
their inter-arrival behavior, multiplicity of sources and multiplicity  
of destinations, remains legit in my humble opinion.

Just like ignoring  DSCP bits at the peering interface is legit at  
this time.

Its like the post office getting envolopes by the truckload, then  
opening each envelope, read the content, to decide when to send the  
opened letter for delivery, either by foot or car, claiming that such  
a decision process will prevent envelopes from flooding the post  
office, coming into the post office for delivery in the last mile.

On the other hand, traffic management such as flow management, deal  
with stuff differently by ensuring that the envelopes do not get to  
the post office too fast, thus permitting the letters be dispatched  
always by car, except those envelopes which are arriving to the post  
office, exhibiting behaviour of P2P, which are then sent for delivery  
by foot.  In this latter case, the envelopes are never opened.

F.
--
François D. Ménard
francois at menards.ca



On 1-Mar-09, at 11:32 AM, Lorell Hathcock wrote:

> Francois:
>
> Should your email have also included a French interpretation as well?
>
> Sincerely,
>
> Lorell Hathcock
> -----------------------------------------------------
> Francois :
>
> Votre email devrait-il avoir également inclus une interprétation  
> française
> aussi bien ?
>
> Sincèrement,
>
> Lorell Hathcock
>
> -----Original Message-----
> From: Francois Menard [mailto:francois at menards.ca]
> Sent: Saturday, February 28, 2009 3:51 PM
> To: nanog list
> Subject: DPI or Flow Management
>
> The Coalition of Internet Service Providers has filed a substantial
> contribution at the CRTC stating:
>
> 1) The CRTC should forbid DPI, as it cannot be proven to be 98.5%
> effective at trapping P2P, such as to guarantee congestion relief
>
> 2) The CRTC should allow for other forms of traffic management by
> ISPs, such as Flow Management
>
> http://www.crtc.gc.ca/public/partvii/2008/8646/c12_200815400/1029835.zip
>
> This is part of the public record at the following address:
>
> http://www.crtc.gc.ca/PartVII/eng/2008/8646/c12_200815400.htm
>
> The world will see Canada taking head-on the issue of addressing the
> legitimacy of DEEP PACKET INSPECTION as a mean of properly managing an
> incumbent's network behind the unbundling/peering interface.
>
> NANOG cannot pretend that this debate does not take place and remain
> silent on this.
>
> Best regards,
>
> F.
> --
> François D. Ménard
> francois at menards.ca
>
>
>
>
>
>





More information about the NANOG mailing list