Re: Admission field in QSPEC -- was RE: Review ofdraft-ietf-nsis-qspec-18.txt

Martin:

QSPEC is not for ITU-T standard-specific QOS draft.

Only in Y.xxxx section MAY contain Y.xxx-specific admission priority.

However, QSPEC spec MUST include "General purpose" admission priority.

Is this clear to the group? Or, we we like to go for another cycles of emails for another year?

Best regards,
Radhika

----- Original Message -----
From: Martin Stiemerling 
Date: Friday, March 7, 2008 7:53
Subject: Re: [NSIS] Admission field in QSPEC -- was RE: Review ofdraft-ietf-nsis-qspec-18.txt
To: Gerald Ash 
Cc: nsis 

> Hi Jerry,
> 
> Thanks for your summary and the proposal to change the field.
> 
> However, there current approach elimantes the idea of having an 
> object understood by all participating partners (RSVP, NSIS, etc) 
> in terms of the admission priority.
> 
> The updated QSPEC will solely have the "Y.2171 Admission Priority" 
> but no general purpose admission priority (as in draft-ietf-tsvwg-
> emergency-rsvp). 
> 
> How about having the "Y.2171 Admission Priority" and the general 
> purpose admission priority in the QSPEC?
> 
> Thanks,
> 
> Martin
> 
> [email protected] <== NEW ADDRESS
> 
> NEC Laboratories Europe - Network Research Division
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On 
> > Behalf Of Gerald Ash
> > Sent: Friday, February 29, 2008 7:46 PM
> > To: nsis
> > Cc: John Loughney
> > Subject: Re: [NSIS] Admission field in QSPEC -- was RE: 
> > Review ofdraft-ietf-nsis-qspec-18.txt
> > 
> > All,
> > 
> > I agree with Ken that we are talking past each other at this 
> > point. Magnus has requested to resolve this issue quickly, 
> > so I also agree with Ken to resolve the issue based on his 
> > suggestion in 
> > http://www.ietf.org/mail-archive/web/nsis/current/msg08257.html:
> > 
> > "If the name of the field in Section 5.2.9 of the QSPEC is 
> changed to
> > "Y.2171 Admission Priority", I'll be more than happy to drop 
> > the subject altogether, and suggest we'll note in 
> > [emergency-rsvp] draft that Admission Priority field is not 
> > directly comparable with that in the QSPEC so as to avoid 
> confusion."> 
> > I agree that the qspec approach and emergency-rsvp approach 
> > are not directly comparable, in fact, they are very 
> > different. At the risk of (again) 'being a bit much', let me 
> > elaborate one more time on the differences as I see them:
> > 
> > As I've stated before, IMO admission priority should apply 
> > end-to-end and across administrative domains, and the only 
> > way to do that is to standardize the admission priority 
> > values in an IANA registry. This is the approach taken in 
> > qspec, where the initial values to populate the admission 
> > priority registry have been taken from Y.2171 since AFAIK 
> > this is the only SDO to standardize admission priority levels 
> > so far. The process to standardize these has been rigorous 
> > and agreed to by essentially all service providers (and 
> > equipment vendors). However, these are only initial values 
> > to populate the registry and it does *not* mean that only the 
> > ITU can change the registry to include more or changed 
> > values. E.g., Ken can propose his 'Scavenger Service' (less 
> > than Best Effort) through the standard IANA procedure 
> > specified in qspec Section 7 (IANA considerations):
> > 
> > "Admission Priority Parameter (8 bits):
> > The following values are allocated by this specification:
> > 0-2: assigned as specified in Section 6.2.9:
> > Admission Priority 0: best-effort priority flow
> > 1: normal priority flow
> > 2: high priority flow
> > The allocation policies for further values are as follows:
> > 3-63: Standards Action
> > 64-255: Reserved"
> > 
> > In addition, the qspec approach is the same as used in 
> > practice today for emergency telecommunications services 
> > (ETS, e.g., GETS) to achieve end-to-end admission priority 
> > across domains. One reference as how this approach operates 
> > in practice today for ETS/GETS can be found in 
> > http://www.amazon.com/Traffic-Engineering-Optimization-Integra
> > ted-Networks/dp/0123706254/ (apologies for self reference, 
> > but I'd be very happy to hear other references to 
> > implementation examples). The same reference also presents 
> > extensive modeling & simulation analysis to show how this 
> > approach can operate across domains in the Internet.
> > 
> > OTOH, the emergency-rsvp approach is very different. It does 
> > not prescribe end-to-end cross domain consist treatment of 
> > admission priority. As stated in Section 2 of emergency-rsvp:
> > 
> > "As an example of operation across multiple administrative 
> > domains, a 
> > first domain might decide to provide network layer 
> > admission priority 
> > to calls of a given Application Level Resource Priority and 
> map it 
> > into a high RSVP admission control priority inside the 
> Admission 
> > Priority Policy Element; while a second domain may decide to 
> not 
> > provide admission priority to calls of this same Application 
> Level 
> > Resource Priority and hence map it into a low RSVP 
> > admission control 
> > priority."
> > 
> > So in this RSVP approach an ETS/GETS service might *not* get 
> > uniformly high admission priority treatment across 
> > administrative domains (ADs), depending on how the policy 
> > decision points (PDPs) in each AD decide to populate the RSVP 
> > Admission Priority element. Furthermore, my understanding is 
> > that the PDP in each AD is expected to always key off the 
> > Application Level Resource Priority (based on the SIP 
> > resource priority header). These are 2 major differences 
> > with the qspec approach. I presume, however, that the RSVP 
> > admission priority approach is implemented (or planned to be 
> > implemented) in real network applications. It would be nice 
> > to be enlightened RE implementations, existing or planned, if 
> > possible.
> > 
> > A further suggestion is to re-name the RSVP approach > > Admission Priority> to distinguish it from > > Priority>, so that neither approach should be considered a 
> > 'generic' approach.
> > 
> > Barring any objection, I'll go ahead and modify the qspec 
> > draft to rename to > > Priority>, as agreed.
> > 
> > Jerry
> > 
> > 
> > Gerald Ash wrote: 
> > 
> > All,
> > 
> > John writes in 
> > http://www.ietf.org/mail-archive/web/nsis/current/msg08243.html:
> > 
> > John> Just some background history. There are 3 
> > documents defining similar
> > John> fields
> > John>
> > John> tsvwg-emergency-rsvp 
> > John> nsis-qspec 
> > John> dime-qos-parameters
> > John>
> > John> We discussed this on this list and at previous 
> > IETF meetings.
> > John> My view of consensus was that...
> > 
> > I've seen no discussion on the list either before or 
> > after the 'Proposed Resolution' was posted on 3 December at 
> > http://www.ietf.org/mail-archive/web/nsis/current/msg08155.htm
> > l 
> > > > ml> . This is just presented and not explained. AFAICT no 
> > co-authors of the QSPEC document participated actively in the 
> > off-line discussion or explicitly agreed to the proposed 
> > resolution. So I don't see that there was any 'consensus'.
> > 
> > John> ... there should be some harmony and
> > John> a common registry between these documents. 
> > 
> > The proposed resolution says:
> > 
> > "o Regarding Admission Priority:
> > * every protocol spec will only indicate that "higher 
> > value means higher priority".
> > * there is no attempt to define what specific values 
> > should be used for what. this is left outside the scope of 
> > the protocol specs.
> > * each protocol spec will add a statement clarifying 
> > that a given Admission Priority is to be encoded with the 
> > same value in each of the three protocol spec. For example, 
> > in tsvwg-emergency-rsvp, under section 3.1. we will add:
> > " A given Admission Priority is encoded in this 
> > information element
> > using the same value as when encoded in the Admission Priority
> > parameter defined in section 6.2.9 of [nsis-qspec], or 
> > in the Admission
> > Priority parameter defined in section 4.10 of 
> > [dime-qos-parameters].
> > In other words, a given value in any of the 
> > [emergency-rsvp] Admission
> > Priority information element, the [nsis-qspec] 
> > Admission Priority parameter
> > or the [dime-qos-parameters] Admission Priority 
> > parameter, refers to
> > the same Admission Priority.
> > "
> > * the mirror statement will be added in nsis-qspec 
> > (section 6.2.9) and dime-qos-parameters (section 4.10)"
> > 
> > The above proposed resolution is very unclear and does 
> > not begin to explain that (apparently) what is proposed is to 
> > drop the QSPEC approach to admission priority and replace it 
> > with the emergency-rsvp approach. 
> > 
> > Admission priority is a well defined concept supporting 
> > priority in flow admission control. There are 3 priority 
> > levels defined in QSPEC, following the agreement standardized 
> > in Y.2171 http://www.itu.int/rec/T-REC-Y.2171/en. The intent 
> > is that 'high admission priority' is reserved for emergency 
> > telecommunications. 'Normal admission priority' is reserved 
> > for traffic that is not as critical as emergency 
> > telecommunications but requires better than 'best effort 
> > admission priority'. Examples include real-time services 
> > (VoIP, video), VPN and data services. 'Best effort admission' 
> > priority is reserved for a broad class of traffic that can be 
> > considered the lowest priority best effort flows. Examples 
> > include "traditional" ISP services (e-mail, web surfing). 
> > 
> > According to Francois (see 
> > http://www.ietf.org/mail-archive/web/nsis/current/msg08251.htm
> > l), the emergency-rsvp approach is something aligned with 
> > preemption priority where no standard admission priority 
> > values are standardized in a registry. However preemption 
> > priority works in a completely different way than admission 
> > priority; there are 2 values; 'defending priority' and 
> > 'preemption priority'. These can be assigned somewhat 
> > arbitrarily since only the *relative* values have 
> > significance. That is, the absolute values don't matter, it 
> > is only the relative value that matters. In this way 
> > preemption can work across domains without standarding 
> > absolute values of defending priority and preemption 
> > priority. It is unclear how such an approach can work for 
> > admission priority since the decision to admit or not admit a 
> > flow is done at the time of flow admission control and there 
> > is no prior 'defending priority' assigned to a flow when it 
> > first arrives for admission control. So it unclear how the 
> > emergency-rsvp approach is aligned with the preemption 
> > priority approach.
> > 
> > According to Ken (see 
> > http://www.ietf.org/mail-archive/web/nsis/current/msg08248.htm
> > l), the emergency-rsvp approach involves using policy 
> > elements, PDPs doing 'mappings', preemption, and namespaces. 
> > AFAIK preemption priority doesn't have namespaces, and what 
> > Ken describes looks different from what Francois describes. 
> > 
> > In any case it appears that emergency-rsvp is doing 
> > something quite different from what QSPEC is doing.
> > 
> > John> I think wee need to be able to support a few 
> > different scenarios and usages 
> > John> for the admission priority.
> > 
> > I'm not sure what 'different scenarios' we're trying to 
> > support here? As discussed above, admission priority is a 
> > well defined concept supporting priority in flow admission 
> > control. I've seen no mention of any other 'different 
> > scenarios' for admission priority on the list. Can you elaborate?
> > 
> > John> Is there a way that we could have a common 
> > structure to hold
> > John> the values, and the ability to set the values accordingly?
> > 
> > Obviously one option is for emergency-rsvp to adopt the 
> > approach being taken all along in QSPEC. We are not being 
> > told why this is not considered. 
> > 
> > Francois> Perhaps another option could be for the Qspec 
> > document to state
> > Francois> that the Admission Priority values MAY be set 
> > according to Y.2171
> > Francois> (but not mandate those are the only valid 
> > assignment and not
> > Francois> request creation of a Qspec-specific IANA 
> > registry for those)?
> > 
> > This is essentially the same as the 'proposed 
> > agreement', i.e. to drop the QSPEC approach to admission 
> > priority and do away with standardized admission priority 
> > values. If we eliminate this standardization, then different 
> > admission priority values can be assigned in different Admin 
> > domains, and will have no end-to-end significance. As such, 
> > each Admin domain has no idea how to treat the flow admission 
> > priority during flow admission since different domains are 
> > using different encodings of admission priority.
> > 
> > IMO we should retain the standardized admission 
> > priority levels as included in QSPEC for a long time. If 
> > emergency-rsvp cannot adopt the same approach, then for now 
> > retain 2 approaches.
> > 
> > Jerry
> > ________________________________
> > 
> > Never miss a thing. Make Yahoo your homepage. 
> > 
> > 
> > 
> > ________________________________
> > 
> > Never miss a thing. Make Yahoo your homepage. 
> > 
> > 
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis
>