Re: Admission field in QSPEC -- was RE: Review ofdraft-ietf-nsis-qspec-18.txt
"James M. Polk" <[email protected]>
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Message-ID | <[email protected]> |
Gerry
So, let me get this straight (from you), you are backing only an
Admission priority indicator (a field) that travels only end2end or
not at all (because that's the way "all SPs and vendors have agreed to")?
If true, you only see one of the following scenarios working
Scenario 1 - RSVP e2e
+----------+ +----------+ +---------+ +---------+
| RSVP |<->| RSVP |<->| RSVP |<->| RSVP |
+----------+ +----------+ +---------+ +---------+
Domain1 Domain2 Domain3 Domain4
Scenario 2 - RSVP start/end, NSIS somewhere in the middle
+----------+ +----------+ +---------+ +---------+
| RSVP |<->| NSIS |<->| RSVP |<->| RSVP |
+----------+ +----------+ +---------+ +---------+
Domain1 Domain2 Domain3 Domain4
Scenario 3 - RSVP start/end, NSIS as the middle
+----------+ +----------+ +---------+ +---------+
| RSVP |<->| NSIS |<->| NSIS |<->| RSVP |
+----------+ +----------+ +---------+ +---------+
Domain1 Domain2 Domain3 Domain4
Scenario 4 - NSIS start/end, RSVP as the middle
+----------+ +----------+ +---------+ +---------+
| NSIS |<->| RSVP |<->| RSVP |<->| NSIS |
+----------+ +----------+ +---------+ +---------+
Domain1 Domain2 Domain3 Domain4
Scenario 5 - NSIS start/end, RSVP somewhere in the middle
+----------+ +----------+ +---------+ +---------+
| NSIS |<->| NSIS |<->| RSVP |<->| NSIS |
+----------+ +----------+ +---------+ +---------+
Domain1 Domain2 Domain3 Domain4
Scenario 6 - NSIS e2e
+----------+ +----------+ +---------+ +---------+
| NSIS |<->| NSIS |<->| NSIS |<->| NSIS |
+----------+ +----------+ +---------+ +---------+
Domain1 Domain2 Domain3 Domain4
The only one you see working is scenario 6 because it is NSIS e2e. I
know this is the NSIS WG list, but do you believe it is realistic or
idealistic to advocate (what seems like) a
my-way-or-I-oppose-all-other-ways direction?
Shouldn't there be a means for interoperability without 100%
comformance to 1 way of doing a thing?
Just looking for clarification with diagrams, so I can visualize what
you're really saying.
James
At 02:57 PM 3/7/2008, Gerald Ash wrote:
>Martin,
>
> > Thanks for your summary and the proposal to change the field.
>
>It wasn't my proposal, it was Ken's proposal who said that if
>adopted he would "be more than happy to drop the subject
>altogether." However, it seems now that this agreement wasn't
>enough to drop the subject altogether after all.
>
> > 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).
>
>Note that the emergency-rsvp folks would prefer to call the rsvp
>admission priority "generic admission priority" (GAP). The object
>used for GAP is as follows (see Section 3.1
>of
><http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-05.txt>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-05.txt):
>
>3.1. Admission Priority Policy Element
>
> The format of the Admission Priority policy element is as follows:
>
> 0 0 0 1 1 2 2 3
> 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
> +-------------+-------------+-------------+-------------+
> | Length | P-Type = ADMISSION_PRI |
> +-------------+-------------+-------------+-------------+
> | Flags | M. Strategy | Error Code | Reserved |
> +-------------+-------------+-------------+-------------+
> | Reserved |Adm. Priority|
> +---------------------------+---------------------------+
>This is an rsvp-specific object and if incorporated into qspec would
>lead to significant changes (probably also in qos-nslp). IMO this
>would be a very bad approach.
>
> > How about having the "Y.2171 Admission Priority" and the
> > general purpose admission priority in the QSPEC?
>
>A possible approach would be to add an L bit in the NSIS admission
>priority object, as follows (see Section 5.2.9 in
><http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt>http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt):
>
>5.2.9 <Admission Priority> Parameter [Y.2171]
>
> The coding for the <Admission Priority> parameter is as follows:
>
>0 1 2 3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|M|E|N|r| 9 |r|r|r|r| 1 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Admis.Priority|L| (Reserved) |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> High priority flows, normal priority flows, and best-effort priority
> flows can have access to resources depending on their admission
> priority value, as described in [Y.2171], as follows:
>
> Admission Priority:
>
> 0 - best-effort priority flow
> 1 - normal priority flow
> 2 - high priority flow
>
> L bit:
>
> 0 - admission priority field has end-to-end significance
> (above admission priority values in IANA registry apply)
> 1 - admission priority field has local significance only
> (admission priority values set by local domain administrator)
>
>In order to have this understood by all participating partners, it
>would be best if emergency-rsvp would also adopt the L bit with the
>same semantics.
>
>It would be good to get some other opinions here, besides the 4 or 5
>of us who have discussed this so far.
>
>Jerry
>
>
>Martin Stiemerling <[email protected]> wrote:
>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
>
>
>Looking for last minute shopping deals?
><http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping>Find
>them fast with Yahoo! Search.
>_______________________________________________
>nsis mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nsis