Subject: RE: [Tsvwg] <draft-lefaucheur-emergency-rsvp>

From: Janet P Gunn <[email-masked]>
Date: Fri, 6 Oct 2006 15:02:06 -0400

There seems to be some confusion about whether ot not this draft addresses
only the "without preemption" situation, or whether it also addresses the
"preemption" case.

1.1 (related work)  says:
 “   In contrast to [EMERG-IMP], this document specifies new RSVP
     extensions to increase the probability of call completion without
    preemption. Engineered capacity techniques in the form of
    bandwidth
    allocation models are used to satisfy the "admission priority
    required by an RSVP capable ETS network.”

 And the text above charts 5 and 9 in A.1 implies that preemption is
 out of
 scope:
 “ …they
    may be handled by mechanisms, which are beyond the scope of this
    particular document (such as establishment through preemption of
    existing non-priority sessions,…”

 But section 2 says:
 “ As can be observed, the framework described above for
    mapping/remapping application level resource priority requirements
    into an RSVP admission priority can also be used for
    mapping/remapping application level resource priority requirements
    into an RSVP preemption priority (when preemption is indeed
 needed).”

 And 3.1 says:
 “ Note that the Admission Priority Policy Element does NOT indicate
    that this RSVP reservation is to preempt any other RSVP
 reservation.
    If a priority session justifies both admission priority and
    preemption priority, the corresponding RSVP reservation needs to
    carry both an Admission Priority Policy Element and a Preemption
    Priority Policy Element. The Admission Priority and Preemption
    Priority are handled by LPDPs and PEPs as orthogonal and
 independent
    mechanisms.”

 And Appendix B specifically looks at preemption.
 “   If one wants to implement an emergency service based on Call
 Queueing,
    on "prioritized access to network layer resources", and ensure
 that
    "emergency" sessions can preempt regular sessions, one could do
 that
    by signaling emergency calls:
       * using "Resource-Priority" Header in SIP
       * using Admission-Priority Policy Element in RSVP
       * using Preemption Policy Element in RSVP with:
             o setup (Emergency) > defending (Non-Emergency)
             o setup (Non-Emergency) <= defending (Emergency)”

I think it would be clearer if the draft clearly distinguished between
"stuff that applied to both the preemption and no preemption cases", "stuff
that applies only to the preemption cases", and "stuff that applies only to
the non-preemption case", as is done in RFC4412.

 RPH related Nits.-
 drsn needs 6 values, not 5.

When converting dsn and dsrn priority values in text (e.g., "routine",
"flash") to numerioc values, it appears that the plan (in other contxts) is
to use 0 for "routine" and higher number for higher priorities.  However
ets and wps use 0 for the highest priority.

In this context, I don't know whether it makes sense to be internally
conistent (0 = highest), or to be consistent with the encoding used in the
RPH (with 0 highest for ets and wps, and 0 lowest for dsn and dsrn).

I would also be interested in comments on the relationship between this
draft and
draft-baker-tsvwg-admitted-voice-dscp-01.

In particular, a clarification of exactly what "engineered capacity" means,
and how  "RSVP-routers to enforce such admission priority on
   every link" would help make it clearer.

Thanks,

Janet

---

From: ken carlberg <[email-masked]>
Date: Mon, 9 Oct 2006 09:57:17 -0400

Hi Janet,

Thanks for the comments.  I think some confusion can come about in  
micro-examination of some text when not considering the text as a  
whole and where it is placed in the document.  Having said that  
though, we'll look into adding some text to make things that much  
more clearer.

>  out of scope:

yes, preemption as we see it in classic MLPP-type networks (eg,  
Autovon) and [EMERG-IMP] is out-of-scope in this document as a  
*binary* type action in presence of congestion (put another way, lack  
of resources).  We can probably add this statement to further qualify  
our comment can be added.

As we state in the first paragraph of Section 1 (Intro), the focus of  
the draft is probability, which in some extreme cases may reach  
100%.  The distinction is subtle, but it exists.

>     into an RSVP preemption priority (when preemption is indeed

here it is important to take into consideration the _entire_  
paragraph from which you extract the above text.  For later in the  
paragraph, we state:

    In that case, when processing the RSVP Application-Level Resource-
    Priority Policy Element, the PDPs at boundaries between
    administrative domains (or between various QoS signaling protocols)
    can map it into an RSVP "preemption priority" information. This
    Preemption priority information comprises a setup preemption level
    and a defending preemption priority level. This preemption priority
    information can then be encoded inside the Preemption Priority  
Policy
    Element of [RSVP-PREEMP] and thus, can be taken into account at  
every
    RSVP-enabled network hop as discussed [EMERG-IMP]. Appendix B
    provides examples of various hypothetical policies for emergency  
call
    handling, some of them involving admission priority, some of them
    involving both admission priority and preemption priority.  
Appendix B
    also identifies how the Application-Level Resource Priority need to
    be mapped into RSVP policy elements by the PDPs to realize these
    policies.

Meaning there is a need to rely on [RSVP-PREEMP], with its preemption  
level and defending preemption priority level.  And we then point the  
reader to Appendix B for further discussion on the topic.  However,  
given your confusion, we'll try and clarify the paragraph a bit more.

>     independent  mechanisms.”

And we initially bring up this discussion from the rest of the  
paragraph in Section 2 that I include above, and push the reader to  
Appendix B for more text on the subject.  I think this works well and  
is consistent.

>    that by signaling emergency calls:

Perhaps here it would be helpful to recap some history in previous  
discussions of the draft (on list and at the meetings).  In the past,  
the text in the appendix was in the body of the draft.  However,  
Allison Mankin, in her role as AD and co-chair of TSVWG at the time)  
requested that discussion of potential "use" of the proposed  
extension be placed outside the body of the draft and into an  
appendix -- which we have done.  In the body, we have some discussion  
on related work and where we saw the need, we mentioned the subject  
of preemption and pointed people to the appendix for further discussion.

rfc-4412 has everything -- specification, examples, etc -- in the  
body of the draft.  I'll defer to my co-authors/chairs/AD, but I'd  
prefer to keep the structure of our draft as is and move discussions  
of how to use the extension to the appendix.  But as stated earlier,  
we'll look into adding some text to make things a bit clearer.

>  drsn needs 6 values, not 5.

ok.  we'll update the draft.

> RPH (with 0 highest for ets and wps, and 0 lowest for dsn and dsrn).

its possible I missed something, but this would be something to take  
up with IANA when defining numeric based NameSpace.Value tupples.

> draft-baker-tsvwg-admitted-voice-dscp-01.

understandable, though I'd prefer to see the discussion placed in the  
Baker draft.  Fred or James can correct me, but the draft you cite is  
a bit broader in scope while ours is quite specific in terms of an  
extension to RSVP.  We add some further context in the appendix, but  
I'd personally feel a bit uncomfortable going beyond the scope of  
what we have already covered.

>    every link" would help make it clearer.

ok.  we can add some text on what engineered capacity means.  I  
haven't checked yet, but I would assume there is an abundant number  
of MPLS/TE rfcs & drafts that cover this topic.  Perhaps we can point  
the reader to one or more of those efforts.

regards,

-ken

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 10 Oct 2006 09:40:32 +0200

Hello Janet,

Thanks for your comments.

>> only the "without preemption" situation, or whether it also  

The draft aims at:
	- specifying an RSVP extension (Admission Priority) which allows to  
increase the probability. This new RSVP extension does not involve  
call preemption.
	- describing how Application Level priority can be mapped into  
various RSVP mechanisms (such as the newly defined RSVP Admission  
Priority, or the existing RSVP Preemption Priority)

With this in mind, I think the current text reflects this reasonably  
accurately.

Still, Ken and I will walk through the text you pointed out and clean  
up as needed.

>>  drsn needs 6 values, not 5.

Just to be clear, the current text does not say that drsn has 5 values.
It says that for each namespace, you list the values as defined by  
IANA and we give one example for the dsn namespace (which has 5).
But we can add the DRSN example, if that helps.

>> RPH (with 0 highest for ets and wps, and 0 lowest for dsn and dsrn).

Could you point out the documents which define the mapping from text  
values to numeric values?
Perhaps we could plan a face to face discussion in San Diego on this  
encoding.

> its possible I missed something, but this would be something to  
> take up with IANA when defining numeric based NameSpace.Value tupples.

> understandable, though I'd prefer to see the discussion placed in  
> the Baker draft.  Fred or James can correct me, but the draft you  
> cite is a bit broader in scope while ours is quite specific in  
> terms of an extension to RSVP.  We add some further context in the  
> appendix, but I'd personally feel a bit uncomfortable going beyond  
> the scope of what we have already covered.

Like Ken, I'd prefer if this relationship could be discussed in the  
new draft.

> ok.  we can add some text on what engineered capacity means.

Agreed.

Cheers

Francois

> I haven't checked yet, but I would assume there is an abundant  
> number of MPLS/TE rfcs & drafts that cover this topic.  Perhaps we  
> can point the reader to one or more of those efforts.
>
> regards,
>
> -ken

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 10 Oct 2006 12:27:03 -0400

ken carlberg <[email-masked]> wrote on 10/09/2006 09:57:17 AM:

> ...
> ...
I should have been clearer, as I actually meant two distinct things.

First, the NSIS RMD document, which is in some ways analogous to this
document, at least in reference to "admission priority", explicitly makes
the point: " In
   this case three types of priority traffic classes within the same
   PHB, e.g., Expedited Forwarding, can be differentiated. These three
   different priority traffic classes, which are associated to the same
   PHB, are denoted in this document as PHB_low_priority,
   PHB_normal_priority and PHB_high_priority."

This document does not seem to have the same sort of statement, although
_I_ infer that this is also the case here.  So it would be useful to either
confirm or deny this inference within the document.

In particular, since the new draft
(draft-baker-tsvwg-admitted-voice-dscp-01) proposes a new DSCP for EF, but
not a new PHB, it would be useful to understand whether this RSVP
admission priority applies across a single DSCP, or across a single PHB
(possibly with multiple DSCP), or whether I am completely missing the
point, and there is no relationship to either the DSCP or the PHB.

My second point is that, since both these drafts (
draft-lefaucheur-emergency-rsvp and draft-baker-tsvwg-admitted-voice-dscp)
address priority admission, it would be useful to have discussion about
their relationship ON THE LIST.

Thanks

Janet

---

From: ken carlberg <[email-masked]>
Date: Tue, 10 Oct 2006 13:30:11 -0400

Janet,

>    PHB_normal_priority and PHB_high_priority."

first and foremost, which RMD document are you talking about, and  
where does the above passage come from?  If I remember correctly,  
there are 5 RMD documents in the NSIS wg.

> confirm or deny this inference within the document.

I'm sorry for being a bit dense, but I just don't understand the  
question or inference.  what does EF and PHB's (and those with names  
of "_low_", "_normal_", "_high_" in an RMD draft) have to do with the  
RSVP extensions draft?   (perhaps James or Francois can provide some  
insight)

If you're asking for a roadmap of how one can intertwine different  
efforts (if so desired), that is probably something that goes in  
another document which is possibly an I-D, or a white paper, or even  
an RFP depending on what one wants to accomplish.

> their relationship ON THE LIST.

again, in the near term, I think this is a topic for Fred, James, or  
Martin.  Guys, feel free to change the subject line and jump on in :)

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 10 Oct 2006 14:20:52 -0400

> there are 5 RMD documents in the NSIS wg.

I am referring to <draft-ietf-nsis-rmd-07.txt>
> RSVP extensions draft?   (perhaps James or Francois can provide some

It is also quite possible that I am the one being dense, which is why I
would like clarification.

---

From: ken carlberg <[email-masked]>
Date: Thu, 12 Oct 2006 10:34:13 -0400

Hi Janet,

Sorry for the tardy response.  In considering the RMD document <draft- 
ietf-nsis-rmd-07.txt> in relation to the <draft-lefaucheur-emergency- 
rsvp-02.txt> document, one needs to peek into the NSIS QSpec <draft- 
ietf-nsis-qspec-12.txt> from which the RMD basis part of its work  
from.....kinda like follow the yellow brick road :-)

in our RSVP extension draft, we have a 3 bit "PRI" (admission  
priority) field, which is what I believe you were originally asking  
about implicitly.  This is a field that was added based on a request  
from a thread on the NSIS list earlier this year in order to add a  
measure of compatibility with the QSpec document, which also has an  
Admission Priority field (stemming from the ITU Y.1541 document). I  
stress a measure as opposed to an exact 1-to-1 mapping of fields  
since it wasn't our intent to an RSVP version of the QSpec work.

In looking at the latest QSpec draft, the Resource Priority field is  
now 8 bits.  We'll extend the size of our field to the same size, and  
we'll look into inverting the values to match that of the QSpec  
field.  So, in a round about way, yes, an inference can be drawn  
between the resource priority fields in the QSpec and our RSVP  
extension draft.  However, having said that, a different (new?) draft  
would be used to describe a more broader perspective and/or  
interaction between the three documents (RMD, QSpec, and our  
emergency-extensions draft).

Also, it would seem that the suite of RMD documents is closer in  
architectural design or objective to the PCN work than that of <draft- 
lefaucheur-emergency-rsvp> and <draft-baker-tsvwg-admitted-voice- 
dscp>.  I say this because the RMD & PCN efforts deal with an  
explicit feedback mechanisms through DSCP (if I've misread this,  
please correct me).

regards,

-ken

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Oct 2006 18:07:01 +0200

Hi Ken 

The sentence Janet referred to is related to a single PHB that uses 
multiple DSCPs. This will be made clearer in the new version of the 
RMD draft.

Best Regards,
Georgios

> -----Original Message-----
> From: ken carlberg [mailto:[email-masked]] 
> Sent: donderdag 12 oktober 2006 16:34
> To: Janet P Gunn
> Cc: tsvwg
> Subject: RMD, QSpec, and RSVP extension,was Re: [Tsvwg] 
> <draft-lefaucheur-emergency-rsvp>
> 
> Hi Janet,
> 
> Sorry for the tardy response.  In considering the RMD 
> document <draft- ietf-nsis-rmd-07.txt> in relation to the 
> <draft-lefaucheur-emergency- rsvp-02.txt> document, one needs 
> to peek into the NSIS QSpec <draft- ietf-nsis-qspec-12.txt> 
> from which the RMD basis part of its work from.....kinda like 
> follow the yellow brick road :-)
> 
> priority) field, which is what I believe you were originally 
> asking about implicitly.  This is a field that was added 
> based on a request from a thread on the NSIS list earlier 
> this year in order to add a measure of compatibility with the 
> QSpec document, which also has an Admission Priority field 
> (stemming from the ITU Y.1541 document). I stress a measure 
> as opposed to an exact 1-to-1 mapping of fields since it 
> wasn't our intent to an RSVP version of the QSpec work.
> 
> In looking at the latest QSpec draft, the Resource Priority 
> field is now 8 bits.  We'll extend the size of our field to 
> the same size, and we'll look into inverting the values to 
> match that of the QSpec field.  So, in a round about way, 
> yes, an inference can be drawn between the resource priority 
> fields in the QSpec and our RSVP extension draft.  However, 
> having said that, a different (new?) draft would be used to 
> describe a more broader perspective and/or interaction 
> between the three documents (RMD, QSpec, and our 
> Also, it would seem that the suite of RMD documents is closer 
> in architectural design or objective to the PCN work than 
> that of <draft- 
> explicit feedback mechanisms through DSCP (if I've misread 
> this, please correct me).
> 
> regards,
> 
> -ken
> 
> 
> >>> First, the NSIS RMD document, which is in some ways analogous to 
> >>> this document, at least in reference to "admission priority", 
> >>> explicitly makes the point: " In
> >>>    different priority traffic classes, which are 
> associated to the 
> >>> same
> >>> This document does not seem to have the same sort of statement, 
> >>> although _I_ infer that this is also the case here.  So 
> it would be 
> >>> useful to either confirm or deny this inference within 
> the document.
> >>
> > It is also quite possible that I am the one being dense, 
> which is why 
> > I would like clarification.
> >
> >>> (draft-baker-tsvwg-admitted-voice-dscp-01) proposes a new 
> DSCP for 
> >>> EF, but not a new PHB, it would be useful to understand 
> whether this 
> >>> RSVP admission priority applies across a single DSCP, or across a 
> >>> single PHB (possibly with multiple DSCP), or whether I am 
> completely 
> >>> missing the point, and there is no relationship to either 
> the DSCP 
> >>> or the PHB.
> >>>
> >>> address priority admission, it would be useful to have discussion 
> >>> about their relationship ON THE LIST.
> >>

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 12 Oct 2006 12:35:16 -0400

Georgios,

THANK YOU.
That clarification really helps, and makes it even more relevant to
draft-baker-tsvwg-admitted-voice-dscp, which adds a new DSCP with EF PHB.

That draft also addresses multiple admission priorities within a single
DSCP.  Is that an approach that would, or would not, be permitted in RMD?

Should we copy this to NSIS since the scope has become broader?

Janet

"Georgios Karagiannis" <[email-masked]> wrote on 10/12/2006

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 13 Oct 2006 11:29:16 +0200

Hi Janet

Yes also admission priorities are allowed within a single DSCP.
Probably it is not clear enough. We will
clarify it in the next version.

Best Regards,
Georgios

> From: Janet P Gunn [mailto:[email-masked]] 
> Sent: donderdag 12 oktober 2006 18:35
> To: Georgios Karagiannis
> Cc: 'ken carlberg'; 'tsvwg'
> Subject: Re: [Tsvwg] <draft-lefaucheur-emergency-rsvp>
> 
> 
> 
> 
> 
> 
> 
> Georgios,
> 
> THANK YOU.
> That clarification really helps, and makes it even more 
> relevant to draft-baker-tsvwg-admitted-voice-dscp, which adds 
> a new DSCP with EF PHB.
> 
> That draft also addresses multiple admission priorities 
> within a single DSCP.  Is that an approach that would, or 
> would not, be permitted in RMD?
>