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

Gerald Ash <[email protected]> Fri, 29 Feb 2008 10:46:07 -0800 (PST)

Newsgroups	gmane.ietf.nsis
Message-ID	<[email protected]>

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-Integrated-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 <RSVP Admission Priority> to distinguish it from <Y.2171 Admission 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 <Admission Priority> to <Y.2171 Admission Priority>, as agreed.

Jerry

Gerald Ash <[email protected]> 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.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