[112503] in North American Network Operators' Group
Re: DPI or Flow Management
daemon@ATHENA.MIT.EDU (Francois Menard)
Sun Mar 1 12:23:10 2009
From: Francois Menard <francois@menards.ca>
To: Lorell Hathcock <lorell@hathcock.org>
In-Reply-To: <025501c99a8b$587cb7f0$097627d0$@org>
Date: Sun, 1 Mar 2009 11:49:18 -0500
Cc: 'nanog list' <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
If by french, you actually are wondering if the time could be afforded =20=
to translate all of the filing to french, and file in both languages, =20=
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 =20
ignoring DSCP bits, and queuing all of the traffic in the same lane, =20
such as to disregard the intended prioritization between the peering =20
parties.
DPI gear instead of ignoring DSCP bits, compute DSCP bits from the =20
content of the packer (so-called application headers).
I agree with various party submissions that the 5-layer Internet model =20=
does not provide for such a concept of headers, which DPI and ILECs =20
and Incumbent Cable Operators, call application headers.
I believe that anything traffic management, which purports to place =20
its hook on application headers, is by definition, violating network =20
neutrality.
However, traffic management in the form of 'pacing packets' based on =20
their inter-arrival behavior, multiplicity of sources and multiplicity =20=
of destinations, remains legit in my humble opinion.
Just like ignoring DSCP bits at the peering interface is legit at =20
this time.
Its like the post office getting envolopes by the truckload, then =20
opening each envelope, read the content, to decide when to send the =20
opened letter for delivery, either by foot or car, claiming that such =20=
a decision process will prevent envelopes from flooding the post =20
office, coming into the post office for delivery in the last mile.
On the other hand, traffic management such as flow management, deal =20
with stuff differently by ensuring that the envelopes do not get to =20
the post office too fast, thus permitting the letters be dispatched =20
always by car, except those envelopes which are arriving to the post =20
office, exhibiting behaviour of P2P, which are then sent for delivery =20=
by foot. In this latter case, the envelopes are never opened.
F.
--
Fran=E7ois D. M=E9nard
francois@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 =E9galement inclus une interpr=E9tation =20=
> fran=E7aise
> aussi bien ?
>
> Sinc=E8rement,
>
> Lorell Hathcock
>
> -----Original Message-----
> From: Francois Menard [mailto:francois@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=E7ois D. M=E9nard
> francois@menards.ca
>
>
>
>
>
>
