RE: [Ieprep] Diffserv Code Point for Emergency calls

"James M. Polk" <jmpolk@cisco.com> Sun, 23 October 2005 03:23 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETWS6-0003LQ-8l; Sat, 22 Oct 2005 23:23:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETWS4-0003I5-CG for ieprep@megatron.ietf.org; Sat, 22 Oct 2005 23:23:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11424 for <ieprep@ietf.org>; Sat, 22 Oct 2005 23:23:04 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETWeX-00063C-On for ieprep@ietf.org; Sat, 22 Oct 2005 23:36:10 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2005 20:23:07 -0700
X-IronPort-AV: i="3.97,241,1125903600"; d="scan'208"; a="355550375:sNHT28280234"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9N3N098022604; Sat, 22 Oct 2005 20:23:05 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 22 Oct 2005 20:23:00 -0700
Received: from jmpolk-wxp.cisco.com ([10.21.80.233]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 22 Oct 2005 20:22:59 -0700
Message-Id: <4.3.2.7.2.20051022220937.029380f8@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 22 Oct 2005 22:22:58 -0500
To: "Reinaldo Penno" <rpenno@juniper.net>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] Diffserv Code Point for Emergency calls
In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2801667705@proton.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 23 Oct 2005 03:22:59.0982 (UTC) FILETIME=[11D482E0:01C5D781]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Cc: ieprep@ietf.org, ken carlberg <carlberg@g11.org.uk>
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org

At 08:45 AM 10/22/2005 -0400, Reinaldo Penno wrote:
>Your point is well taken James.
>
>Therefore, if we just continue with just EF for normal and emergency
>voice calls, the risk is the same, the drawback that I see is that we
>cannot prioritize emergency over normal calls.

so here's the problem as has been presented to me by both regulators and 
lawyers:

In larger emergencies, many people will likely be calling for emergency 
help, and some of them are not going to be calling (the equivalent of) 911, 
they will be calling their doctors directly - yet to "the system", these 
will appear as normal packets, or normal voice (EF marked) packets. In your 
pondering, these packets will be subject to some form of lesser treatment 
than perhaps the 10th or 100th call to 911, informing the PSAP of the same 
event (perhaps a building burning).

Here's the catch: who determined the 10th or 100th call to the PSAP is more 
important than the patient's call with their doctor - getting one-on-one 
advice/help.

I think the first lawsuit will stop that preferential treatment. I've had 
this hinted to me by many


>So, in general an edge device that can perform SIP parsing and mark
>emergency calls with the emergency DSCP and others with EF DSCP.
>Alternatively, in a decomposed gateway scenario the SIP Proxy can let
>the router know that a certain call is an emergency and that it should
>be marked differently.

or there could be a path coupled mechanism for such calls, but that has its 
challenges too


>Regards,
>
>Reinaldo
>
>
> > -----Original Message-----
> > From: James M. Polk [mailto:jmpolk@cisco.com]
> > Sent: Friday, October 21, 2005 11:02 PM
> > To: Reinaldo Penno
> > Cc: ken carlberg; ieprep@ietf.org
> > Subject: Re: [Ieprep] Diffserv Code Point for Emergency calls
> >
> > Reinaldo
> >
> > Adding fuel to a discussion that has churned on many lists over the
>last
> > several years, I'd really want to understand the threat anaylsis
>observed
> > by such a proposal (for a emergency DSCP) to ensure it could not be
>used
> > for a fairly trivial to generate DDOS on the network - even all the
>way to
> > the PSAP, or just used by neighbors wanting the very best throughput
>for
> > their game of Doom.
> >
> > At 10:57 AM 10/21/2005 -0400, ken carlberg wrote:
> > >Hello Reinaldo,
> > >
> > >>I read
> >
> >>http://www.ietf.org/internet-drafts/draft-ietf-ieprep-framework-10.txt
> > >>and was somewhat puzzled at section 4.1.2. I understand that the
>IETF
> > >>wants to be conservative in standardizing new DSCP, but it seems to
>an
> > >>emergency call DSCP would be accepted by the community (am I
>wrong?).
> > >
> > >well, from my own take, I would say that the "community" is not
> > >against an emergency call DSCP per se, but rather awaits specific
> > >proposals with a cautious mindset.  Recall from that section 4.1.2
> > >that there is a need to define a behavior in addition to identifying
> > >a code point.  So if you want a code point of 1 or more bits for
> > >"emergency", what would be its defined forwarding behavior?
> > >
> > >one such proposal, primarily aimed at MLPP, is called Multi-Level
> > >Expedited Forwarding (MLEF) and can be found at:
> > >ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-silverman-
> > >tsvwg-mlefphb-03.txt
> > >
> > >I would also suggest reading a counter proposal that avoids defining
> > >a new DSCP:
> > >ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tsvwg-
> > >mlpp-that-works-02.txt
> > >you can dig around the TSVWG archives over the past 2 months for some
> > >comments on the draft.
> > >
> > >-ken
> > >
> > >
> > >_______________________________________________
> > >Ieprep mailing list
> > >Ieprep@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/ieprep
> >
> >
> > cheers,
> > James
> >
> >                                  *******************
> >                  Truth is not to be argued... it is to be presented.


cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep