Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02

From: ken carlberg <[email-masked]>
Date: Wed, 4 Apr 2007 19:58:11 -0400

My apologies for the tardy response

> Just for the record,  I'd like to repeat a couple of my previous  
> comments, plus a couple of new ones.
>
> This ID discusses the relationship with the "higher level/  
> application level" SIP  protocol in call admission (especially in  
> relation to  the Resource Priority Header- RFC 4412).  I would like  
> to see a similar reference to the relationship to the new proposed  
> DSCP, EF-ADMIT (draft-ietf-tsvwg-admitted-realtime-dscp-00) .  As  
> calls admitted through the processes described in this ID WOULD be  
> subject to "strict CAC", they would be entitled to use of the EF- 
> ADMIT code point.  However, I understand that, since EF-ADMIT is  
> not yet an RFC, it is difficult to reference it directly.  It is  
> certainly not worth delaying this ID to wait for EF-ADMIT.  But if,  
> by some chance, EF-ADMIT reaches RFC status before this document,  
> perhaps a reference could be added. Or perhaps simply a reference  
> to the possibility of different DSCPs being used as a matter of  
> policy.

we have discussed this before on the list and I don't see anything  
that has changed.  we discuss a relationship with an upper layer  
protocol because of the information that can be extracted and placed  
in the policy element.  EF-Admit, or any other diff-serv code point,  
layered relationship and so should be out of scope of this draft.  In  
fact the recent change of the EF-Admit draft, the subsequent comments  
(with presumably more comments to come), keeps it as a moving target,  
and our draft is hopefully progressing to the next stage.  As before,  
I would suggest taking this request the authors of EF-admit and  
seeing if they would add it to their draft, or to come up with a  
separate draft.

> I am the one who suggested the Priority Bypass model.  But it is  
> really just a special case of the Russian Dolls model, with a very  
> big "outside" doll, so I would have no objections if someone wants  
> to remove it (no objections to leaving it, either).

more than one person has suggested the Priority Bypass Model, and  
since it is also distinctly different from the other models described  
in the appendix, we would prefer to keep it in.

> Some of the people who will be interested in the mechanisms  
> described here have a strong aversion to anything involving  
> preemption.  Therefore I would prefer to see a stronger distinction  
> between the preemption related mechanisms and the non-preemption  
> mechanisms.

I don't mean to be difficult, but I just don't see the same problem.   
I look at the places where we mention the word preemption and feel  
that the context is well stated.  I have asked someone else to review  
the draft and hope to hear another opinion from him about this  
matter.  Francois may want to put in his two cents as well.

> For instance, at the end of section 3.1 it says "The Admission  
> Priority and Preemption
>    Priority are handled by LPDPs and PEPs as orthogonal and  
> independent
>    mechanisms. "
> This is a bit of a cop out, as admission policy and preemption  
> policy cannot, in practice, be completely independent.  You can  
> have preemption without separate priority admission.  You can have  
> priority admission without preemption.

you've just lost me because as I read your last two sentences, they  
appear to contract your statement that they cannot be independent.

> But if you have both priority  admission, and preemption, you have  
> to define the interaction, if only which one is applied first.  
> (Appendix B, in fact, describes cases in which admission priority  
> is applied first, and preemption is only applied if admission  
> priority fails.  But other interactions are possible.)  Therefore  
> it would be more realistic to say that, if both are used, the  
> interaction is defined "by local policy, outside the scope of this  
> document".

what we can do in Appendix B is add that other interactions are  
possible.

> Nit-
> In 3.1.1, I don't quite understand what is meant by "Take priority  
> of highest QoS".  It seems to me that the set of all possible QoS  
> specifications is  a partially ordered set (POSET) rather than a  
> fully ordered set.  For instance,  QoS "A" may have stringent  
> requirements for packet dropping, but weak requirements for delay  
> and jitter.  But QoS "B" may have stringent requirements for delay  
> and jitter, but weaker requirements for packet dropping.  It is not  
> immediately obvious to me whether A or B is the "highest QoS".
>
> But the "Highest QoS"  concept is certainly not central to this  
> document, and perhaps it is addressed in detail somewhere else that  
> I have not come across.

Um, you are talking about two different Flowspecs to the degree of  
comparing apples and oranges....which would not be merged.

> Typo?-
> In the last paragraph of 3.2.1 it says:
> "A given ALRP MUST NOT appear more than
>        once. In other words, the outgoing ALRP List is the reunion of
>        the incoming ARLP Lists that are merged."
>
> I suspect that "reunion" is really supposed to be "union".
> I suspect "ARLP" is supposed to be "ALRP"
>
> There is also another place in 3.2 where it says "ARLP", but I  
> think it is supposed to be "ALRP".

thanks, that will be corrected.

> Appendix A
>
> This text appears a couple of times in Appendix A
> "In that case additional priority sessions could not be accepted. Note
>    that this does not mean that such calls are dropped altogether:  
> 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, or such as queuing of new priority
>    session requests until capacity becomes available again for  
> priority
>    traffic)."
>
> It seems to me that, in most cases, preemption is applied by one  
> priority call to OTHER priority calls (which have lower preemption  
> priority), rather than to "non-priority" calls.
>
> Conversely, since priority admission and preemption are "orthogonal  
> and independent", it might be that some of the calls which are "non- 
> priority calls" from an "admission priority" perspective could be  
> "high priority calls" form a "preemption " perspective.  Therefore  
> it would probably be better to say
> "(such as establishment through preemption of existing  sessions,...)"

well, the term "such as" was really meant to convey an example.  we  
can probably clear up the matter by switching "such as" with "for  
example", and state that other variations could exist.

> Appendix B
>
> grammar nit-
> "If one wants to implement an emergency service based on Call  
> Queueing,
>    on "prioritized access to network layer resources", and ensures  
> that
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions,  
> but
>    non-emergency sessions are not affected by preemption, one can do
>    that by signaling emergency calls::"
> is not quite grammatically correct.
>  It needs to be (Changes in CAPS)
> "If one wants to implement an emergency service based on Call  
> Queueing,
>    on "prioritized access to network layer resources", and WHICH  
> ensures that
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions,  
> but
>    non-emergency sessions are not affected by preemption, one can do
>    that by signaling emergency calls:"
> or
> "If one wants to implement an emergency service based on Call  
> Queueing,
>    on "prioritized access to network layer resources", and ENSURE   
> that
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions,  
> but
>    non-emergency sessions are not affected by preemption, one can do
>    that by signaling emergency calls:"

I'm sorry, but I don't see the difference nor the significance of  
capitalizing "ensure" in comparison to the original text.

> Choice of terms-
> Because the use of preemption is politically sensitive in a  
> significant part of the ETS community, I am quite uncomfortable  
> with the example of  "..an emergency service based on Call Queueing,
>    on "prioritized access to network layer resources", and ensure that
>    "emergency" sessions can preempt regular sessions,..."

just for future reference, but it would be helpful to identify the  
section/paragraph when you are taking selected quotes.  The text you  
refer to is Appendix B, 3'rd paragraph of page 27.

> Can we please call it something other than "an emergency service"?
> Otherwise I can see myself, over the next 10 years, having to  
> repeatedly explain that "No, the IETF is NOT saying that an  
> Emergency Service should use preemption".  I know it is only an  
> academic example, but it is going to make things a lot simpler, and  
> be a lot more understandable to that community, it the example is  
> called something else - possibly "a priority service" or   "a  
> precedence service".
>
>  Even if you decide you need to call it "an emergency service" for  
> reasons of consistency, just changing the name in the Preemption  
> Policy Element from "Emergency -1" and "Emergency-2" to something  
> else, such as "Preemption-1" and "Preemption-2" would make it  
> clearer, and help avoid such misunderstanding.

Again, I don't agree.  What you are asking is to cherry pick  
(selectively pick out) based on the constraints of one organization.   
And more importantly, you are speaking of the appendix, which is  
outside the main body of the document.  This document needs to be  
broader in perspective, otherwise it turns into an individually  
submitted draft for organization X.

About a year ago, the appendix was part of the main body, but under  
the suggestion of Allyson Mankin and agreed upon by consensus at one  
of the meetings, we agreed to keep the text (which is only  
informative in nature), and move it to the appendix....which has  
significance in RFCs.

I hope to hear from another reviewer about this.....um, Lou? :-)

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 4 Apr 2007 21:02:50 -0400

In line.

ken carlberg <[email-masked]> wrote on 04/04/2007 07:58:11 PM:

>    Priority are handled by LPDPs and PEPs as orthogonal and independent 
>    mechanisms. " 
> policy cannot, in practice, be completely independent.  You can have
> preemption without separate priority admission.  You can have 

I guess I wasn't clear enough. 

They ARE independent in the sense that you can have one without.

But they are NOT independent in the sense that, if you have both, there is 
an interaction between them (for instance which is applied first).

> (Appendix B, in fact, describes cases in which admission priority is
> applied first, and preemption is only applied if admission priority 
> fails.  But other interactions are possible.)  Therefore it would be
> more realistic to say that, if both are used, the interaction is 
> defined "by local policy, outside the scope of this document".
> 
possible.
Works for me.
>    that this does not mean that such calls are dropped altogether: they 
>    session requests until capacity becomes available again for priority 
>    traffic)." 
> 
Works for me

> Appendix B 
> 
> grammar nit- 
> "If one wants to implement an emergency service based on Call Queueing, 
>    on "prioritized access to network layer resources", and ensures that 
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but 
> "If one wants to implement an emergency service based on Call Queueing, 
>    on "prioritized access to network layer resources", and WHICH ensures 
that 
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but 
> "If one wants to implement an emergency service based on Call Queueing, 
>    on "prioritized access to network layer resources", and ENSURE  that 
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but 

Again, I wasn't clear.  It is simply a question of subject - verb 
agreement
"If one wants to ... ensure"
not 
"If one wants to ... ensures"

> -ken

The rest of your responses are fine with me.

Janet

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 5 Apr 2007 14:52:22 +0200

Hi,
Just catching up on this.
It sounds like Ken and Janet have converged already.

Just a small extra clarification:
>> and jitter, but weaker requirements for packet dropping.  It is  
>> not immediately obvious to me whether A or B is the "highest QoS".
>>
>> document, and perhaps it is addressed in detail somewhere else  
>> that I have not come across.

The terminology of "Take priority of highest QoS" is taken directly  
from RFC3181 whcih defines these "merge strategies". Basically it  
refers to comparing Flowspecs of reservations (so there is no notion  
of packet dropping preference or anything like that - the key  
parameters are bandwidth).  Although Flowspec are not immediately  
comparable (as they include several parameters) RFC3181 mentions that  
there is a local policy behavior for comparing those.

Since the draft already explicitly reference RFC3181 when discussing  
the merge strategies, I think we're covered. But we can always add a  
sentence making this clarification.

Cheers

Francois

On 5 Apr 2007, at 03:02, Janet P Gunn wrote:

> But they are NOT independent in the sense that, if you have both,  
> there is an interaction between them (for instance which is applied  
> first).
>

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 5 Apr 2007 09:30:40 -0400

Francois,

Since the merging strategy is described in 3181, the "Janet doesn't 
understand" is there, and not in this document, so no need to change it 
here.
And now I DO understand .

I am happy with it.

Happy Easter/Passover/Spring,

Janet

Francois Le Faucheur IMAP <[email-masked]> wrote on 04/05/2007 
08:52:22 AM:

> comparable (as they include several parameters) RFC3181 mentions 
> that there is a local policy behavior for comparing those.
> 
independent 
first). 
possible. 

they 
priority 
Queueing, 
that 
but 
Queueing, 
but 
Queueing, 
 that 
but 
agreement