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

[writing as WG member, i.e. WG chair's hat off]

Hi,

I took a while to wrap my head around it, as this touches not only NSIS' business but also other WG's business. 

I see the benefits of the end-to-end approach in general and also in particular for the QSPEC draft. The IETF is good in doing end-to-end protocols but has some issues in defining end-to-end QoS solutions (note the diffence between 'protocols' and 'solutions'). Having end-to-end QoS and signalling of it, is definitetly beneficially but is also troublesome.

We are doing protocols and not architectures, so it is hard to mandate which QoS scheme is used in the Internet or any other closed deployment. This lead to the concept of local QSPEC in the QSPEC draft which solves this at least on the signalling side but not on the semantics side (i.e., what do different bits mean in different domains).

ITU Y.2171 (Admission control priority levels in Next Generation Networks) is manadated for the admission priority in QSPEC regardless of the used admission priority scheme in a single domain. It is intended for NGN networks (which is ITU specific) but does not apply IMHO to the whole Internet as such. This does not excluded in general, but I don't regard ITU Y.2171 as the single scheme for all deployments.

The current definition of the Admission Priority in the QSPEC draft contradicts also the local QSPEC mechanism. A local domain that uses ITU Y.2171 can do this by using a local QSPEC. However, the general Admission Priority in the QSPEC must be free of ITU semantics, as this is from an IETF perspective just one of the possible admission schemes that can be used. 

Long story short: I'm in favour of Francois' proposal for the Admission Priority, posted on Dec 3, 2007:
http://www.ietf.org/mail-archive/web/nsis/current/msg08155.html

  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 ken carlberg
> Sent: Wednesday, February 27, 2008 8:59 PM
> To: Gerald Ash
> Cc: John Loughney; nsis
> Subject: Re: [NSIS] Admission field in QSPEC -- was RE: 
> Review ofdraft-ietf-nsis-qspec-18.txt
> 
> 
> On Feb 27, 2008, at 12:56 PM, Gerald Ash wrote:
> 
> 
> 	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. 
> 
> 
> oh come on.  how many times must be said and in how many 
> ways?  on February 25, 2008 2:50:24 PM EST I stated the following
> 
> "and as far as the current values set by Y.1541, I wish there 
> was support for Scavenger Service, which is considered less 
> than Best Effort (already defined as "0" in Y.1541).  Since 
> I'm not a member of the ITU, I can't advocate this position 
> nor accomplish it if the Admission field of all three drafts 
> <emergency-rsvp>, <dime-qos-parameters> and <nsis-qspec> are 
> subject to values defined by the ITU."
> 
> 
> Put another way, Francois and I have said that we don't want 
> an Admission Priority field to be constrained (limited, 
> burdened,....pick the word of your choice) with pre-existing 
> values, and in particular those that come from a different 
> standards body.  And we are not condemning all other similar 
> practices.  We are not even saying that those of Y.2171 
> cannot be used.
> 
> as for as the agreement that was passed around in nov/dec, 
> you are not a newbie to think that agreements are etched in 
> stone.  they exist to be commented on, hence our letting 
> others on the diameter/tsvwg/nsis list know the results of 
> private discussions.
> 
> 
> 	
> 	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.
> 
> 
> and I brought this up a while back as well.  we have no 
> intention of steam rolling the agreement.  if part of the 
> agreement breaks, it breaks and we'll go our separate ways.  
> 
> and I apologize if this note is sounding a bit rude, but part 
> of this is getting a bit much.
> 
> -ken
> 
>