RE: [Ieprep] Diffserv Code Point for Emergency calls

["Reinaldo Penno" <[e-mail]>]

Hello,

I read draft draft-ietf-tsvwg-mlpp-that-works-02, which I assume it is
your proposal.

Some questions:

1. The example is the end if quite complex. I would like to start with a
bare bores one. Which priority you suggest for everyday 911 calls as
opposed to normal telephone calls? I believe the priorities are below

  The DSN has 5 precedence levels of IEPS in descending order:

        dsn.flash-override

        dsn.flash

        dsn.immediate

        dsn.priority

        dsn.routine

2. It seems to me your proposal and an emergency DSCP are complementary
and not mutually exclusive. If signal with RSVP and if you get
bandwidth, you mark packets with the emergency DSCP.

3. Not trying to simplify things but premise of this proposal is that
all IP phones will support RSVP, right? 

4. Should the phones use RSVP just for emergency calls or for all calls
in general? I guess they should otherwise the other devices would loose
track of how much bandwidth has been consumed?

Thanks,

Reinaldo



> -----Original Message-----
> From: Fred Baker [mailto:[e-mail]]
> Sent: Wednesday, October 26, 2005 11:59 AM
> To: Reinaldo Penno
> Cc: James M. Polk; [e-mail]; ken carlberg
> Subject: Re: [Ieprep] Diffserv Code Point for Emergency calls
> 
>  From my perspective, the question in the data plane is not whether
> the packet is part of an emergency session, but whether it is
> authorized to use the bandwidth. Emergency authorization is a control
> plane problem.
> 
> That is why I have suggested authorization of users to use the EF
> code point during CAC.
> 
> On Oct 22, 2005, at 8:45 AM, Reinaldo Penno wrote:
> 
> > Your point is well taken James.
> >
> > I guess the risk is no different from what we face nowadays with
doom
> > packets marked with EF DSCP. The solution as well is no different
from
> > what we have today to deal with those packets. Usually
> > independently of
> > the DSCP an endpoint might put in a packet, the edge router perform
> > classification and if necessary remarks the packet with whatever
> > DSCP it
> > should have.
> >
> > 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, 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.
> >
> > 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-
> >>> 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
> >>> [e-mail]
> >>> https://www1.ietf.org/mailman/listinfo/ieprep
> >>>
> >>
> >>
> >> 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