Re: Admission field in QSPEC -- was RE: Review of draft-ietf-nsis-qspec-18.txt
Gerald Ash <[email protected]>
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Message-ID | <[email protected]> |
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.html. 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.html), 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.html), 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.
_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis