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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Mar 2007 16:30:01 +0200

This announces the start of the WG last call of "Resource ReSerVation 
Protovol (RSVP) Extensions for Emergency Services" with the intended 
status of proposed standard:

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-02.txt

Please provide positive or negative feedback before the 13th of April.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 28 Mar 2007 15:04:14 -0400

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.

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).

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. 

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.  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".

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.

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".

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,...)"

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:"

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,..." 

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.

Thanks

Janet

Magnus Westerlund <[email-masked]> wrote on 03/26/2007

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 28 Mar 2007 15:04:14 -0400

Nit-

Typo?-

Appendix A

Appendix B

grammar nit-

Choice of terms-

Thanks

Janet