RE: [Ieprep] Diffserv Code Point for Emergency calls

["Steve Silverman" <[e-mail]>]

James,

We can only base our actions on what is detectible.  We can prioritize
calls to 911 (or equivalent).  I don't know
how to detect emergency calls to a doctor's office.  Or at least how
to distinguish emergencies from routine traffic.
In the absence of both user authentication and mind reading
technology, I don't think we can give special treatment to your
doctor's call example. This is another reason to call 911 for
emergencies rather than a doctor's office. I know my wife tells her
patients to call 911 if there is a true emergency.

Steve

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf
> Of James M. Polk
> Sent: Sunday, October 23, 2005 3:50 PM
> To: Reinaldo Penno
> Cc: [e-mail]; ken carlberg
> 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.
Yes it will if there are too many emergency calls.

>
> 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:[e-mail]]
> > > Sent: Saturday, October 22, 2005 8:23 PM
> > > To: Reinaldo Penno
> > > Cc: ken carlberg; [e-mail]
> > > 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:[e-mail]]
> > > > > Sent: Friday, October 21, 2005 11:02 PM
> > > > > To: Reinaldo Penno
> > > > > Cc: ken carlberg; [e-mail]
> > > > > 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-fram
> ework-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
> > > > > >[e-mail]
> > > > > >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.
>
> _______________________________________________
> Ieprep mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ieprep
>


_______________________________________________
Ieprep mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep