RE: [Ieprep] Diffserv Code Point for Emergency calls

"Reinaldo Penno" <rpenno@juniper.net> Sun, 23 October 2005 06:30 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETZMs-0002ru-1X; Sun, 23 Oct 2005 02:30:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETZMq-0002po-FQ for ieprep@megatron.ietf.org; Sun, 23 Oct 2005 02:30:04 -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 CAA17528 for <ieprep@ietf.org>; Sun, 23 Oct 2005 02:29:51 -0400 (EDT)
Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETZZJ-0002Qv-Cx for ieprep@ietf.org; Sun, 23 Oct 2005 02:42:59 -0400
Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Oct 2005 07:29:38 +0100
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Oct 2005 07:29:38 +0100
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Sun, 23 Oct 2005 02:29:36 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ieprep] Diffserv Code Point for Emergency calls
Date: Sun, 23 Oct 2005 02:29:36 -0400
Message-ID: <9BD5D7887235424FA97DFC223CAE3C2801667706@proton.jnpr.net>
Thread-Topic: [Ieprep] Diffserv Code Point for Emergency calls
Thread-Index: AcXXgR/5W72ZlfIsTsG+9OlXr3I43wAFABkQ
From: Reinaldo Penno <rpenno@juniper.net>
To: "James M. Polk" <jmpolk@cisco.com>
X-OriginalArrivalTime: 23 Oct 2005 06:29:36.0811 (UTC) FILETIME=[23A907B0:01C5D79B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Content-Transfer-Encoding: quoted-printable
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

That is also possible and it might happen all the time.

I think the threats you mention are quite valid but they will be no
different if we have an emergency DSCP. The whole problem around
contention of resources will continue to happen.

My point is the same as before. How this hypothetical scenario is any
different from what could happen today? 

For example, today if something happens in an enterprise, will the
emergency calls to 911 have better treatment than the doctor's call? You
can also imagine a reversed scenario where I could argue that if the
call made by the person in the next cubicle to his doctor blocks my call
to 911 I will sue the company/telco. 

Any hospital in the US has the following recording "if this is an
emergency, hang up and dial 911". If you really have an emergency, you
should be calling 911, and not your doctor. If you call your doctor, you
are implicitly telling the "system" that this is not an emergency.

Somebody in a Telco told me that 911 calls are signaled different (which
imply a priority over normal calls). Do you know if this a fact?

Regards,

Reinaldo



> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Saturday, October 22, 2005 8:23 PM
> To: Reinaldo Penno
> Cc: ken carlberg; ieprep@ietf.org
> Subject: RE: [Ieprep] Diffserv Code Point for Emergency calls
> 
> 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