RE: [Ieprep] Diffserv Code Point for Emergency calls
"Reinaldo Penno" <rpenno@juniper.net> Mon, 24 October 2005 04:15 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETtkD-000798-LI; Mon, 24 Oct 2005 00:15:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETtkC-000793-80 for ieprep@megatron.ietf.org; Mon, 24 Oct 2005 00:15:32 -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 AAA11898 for <ieprep@ietf.org>; Mon, 24 Oct 2005 00:15:19 -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 1ETtws-0002LJ-DI for ieprep@ietf.org; Mon, 24 Oct 2005 00:28:39 -0400
Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 05:15:22 +0100
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 05:15:22 +0100
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 Oct 2005 00:15:20 -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: Mon, 24 Oct 2005 00:15:20 -0400
Message-ID: <9BD5D7887235424FA97DFC223CAE3C280166770D@proton.jnpr.net>
Thread-Topic: [Ieprep] Diffserv Code Point for Emergency calls
Thread-Index: AcXYTQYYFK867GbAQ+6X59uC72OxDAAA/MwQ
From: Reinaldo Penno <rpenno@juniper.net>
To: "James M. Polk" <jmpolk@cisco.com>
X-OriginalArrivalTime: 24 Oct 2005 04:15:20.0827 (UTC) FILETIME=[8C552CB0:01C5D851]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8
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
Well, given that PSTN is resource contending having a different circuit is a form of special treatment, isn't it? The analogous in the IP world (which in bandwidth contending) would be to have bandwidth reservation for a certain number of emergency calls? Is that the direction the several WGs are leaning towards? Regards, Reinaldo > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Sunday, October 23, 2005 8:43 PM > To: Reinaldo Penno > Cc: ken carlberg; ieprep@ietf.org > Subject: RE: [Ieprep] Diffserv Code Point for Emergency calls > > Reinaldo > > Actually, the PSTN does not give better priority to 911 calls (vs. normal > calls), they just use separate cirucuits once the 911 call gets to the > first Class-5 switch. Typically, a Class-5 Switch will have a small > number > of dedicated circuits that connect directly to a 911 Selective Router > (which is a special instance of a Class-5 switch). 911 calls are routed > over these dedicated circuits towards the SR to then be routed to the > appropriate PSAP. This isn't really anything special - since the circuit > world is not bandwidth contending, they are circuit contending. > > At 10:55 PM 10/23/2005 -0400, Reinaldo Penno wrote: > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Sunday, October 23, 2005 12:50 PM > > > To: Reinaldo Penno > > > Cc: ken carlberg; ieprep@ietf.org > > > Subject: RE: [Ieprep] Diffserv Code Point for Emergency calls > > > > > > Reinaldo > > > > > > Comments in-line > > > > > > At 02:29 AM 10/23/2005 -0400, Reinaldo Penno wrote: > > > >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? > > > > > > Because, as I see it - and please correct me if I am seeing this > > > incorrectly - that doctor's call in the enterprise will not be starved > >off > > > by any other call. > > > > > > Yet, the way I have understood most, and I think the scenario you have > > > brought up, the emergency calls will starve off, or at least adversely > > > affect existing calls that can be the equivalent of EF marked in > > > treatment. > > > >[[Reinaldo]] > > > >But...the doctor call can will fight for resources in the same level as > >an emergency call. I guess we should introduce the concept of "personal > >emergency" and "collective emergency". If the building is burning up, I > >try to call the fire department, and the person in the next cubicle > >tries to call his priest, which call is more important? I guess this is > >a complex issue. We will not be able to resolve it here. > > > >If the PSTN today gives better priority to 911 calls, we should strive > >to do the same for VoIP calls. > > > >Regards, > > > >Reinaldo > > > > > > > > Plus there is the issue that most employees operate under a subtly > > > different set of laws and rules than the general public, usually > >starting > > > with when an employee candidate signs a contract of employment > >reducing > > > that person's rights in some ways. > > > > > > > > > >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. > > > > > > While in general, I would agree with you, there are some cases in > >which a > > > doctor is who is to be called when you have an issue with something > >under > > > their care. I have experienced this first hand to know it is true in > >the > > > US. > > > > > > >If you call your doctor, you > > > >are implicitly telling the "system" that this is not an emergency. > > > > > > That's the legacy system you are telling. Whereas, with IP, we have > >many > > > more capabilities (or should) to be able to differentiate one call > >from > > > another. I believe that should one of the IETF's (and other SDO's) > >goals > > > for emergency calling. > > > > > > Please review ECRIT WG discussions as there are many references to > >this > > > capability being on the to-do list of many areas dealing with this > > > scenario. > > > > > > > > > >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? > > > > > > Yes, there are special facilities that 911 calls traverse, after the > > > initial Class 5 switch towards the Selective Router, and on to the > >PSAP. > > > > > > > > > >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. > > > > > > > > > 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
- [Ieprep] Diffserv Code Point for Emergency calls Reinaldo Penno
- Re: [Ieprep] Diffserv Code Point for Emergency ca… ken carlberg
- Re: [Ieprep] Diffserv Code Point for Emergency ca… James M. Polk
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Steve Silverman
- RE: [Ieprep] Diffserv Code Point for Emergency ca… James M. Polk
- RE: [Ieprep] Diffserv Code Point for Emergency ca… James M. Polk
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… James M. Polk
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… James M. Polk
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Janet P Gunn
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Steve Silverman
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Dolly, Martin C, ALABS
- Re: [Ieprep] Diffserv Code Point for Emergency ca… Fred Baker
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… GOLDMAN, STUART O (STUART)
- [Ieprep] A suggestion to the chairs Fred Baker
- Re: [Ieprep] Diffserv Code Point for Emergency ca… Fred Baker