Subject: [NSIS] QSPEC, QOSMs, QoS NSLP interactions

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 5 Jan 2007 12:55:52 +0200 (EET)

Hi (especially Dave, Jerry, Georgios, etc.),

I've been following this latest discussion on the QSPEC and QoS NSLP 
interactions, and state machines. I understand (or I think I do) Dave's 
comment that QOSMs (or RMF) should not be able to affect the QoS NSLP 
state machine, and that is a good and valid point.

Yet, how would e.g. reservation and signaling aggregation (e.g. the 
mentioned separate signaling session for local domain use),  
resource pre-emption or the local QSPEC concept work? Don't these in fact 
change the normal operation of the QoS NSLP at the edges of a special 
treatment domain?

Since one of the main purposes of the QSPEC is to allow a QNI to request 
something e2e, and QNEs along the way MUST commit to that exact request 
(not downgrading anything, upgrading would be fine, right?) but how they 
do it is not fixed, doesn't this apply also to the QoS NSLP, so something 
along

"The end-to-end semantic and QoS NSLP messaging by the QNI, or any peer 
QNE MUST BE preserved, and within those bounds a QOSM must operate."

This means that e.g.,
a) The resource request by the QNI and response from the QNR must be 
   followed and passed through intact by a QOSM X domain,
b) confirmation requests must be answered,
c) tear-down must be followed, etc.

Jukka

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 5 Jan 2007 12:05:10 +0100

Hi Jukka

In other words you are saying that a QOSM could affect the 
QOS-NSLP state machine only if:
"The end-to-end semantic and QoS NSLP messaging by the QNI, 
or any peer QNE MUST BE preserved, and within those bounds a 
QOSM must operate." 

If yes, then I agree with the above!

Best regards,
Georgios

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: vrijdag 5 januari 2007 11:56
> To: [email-masked]
> Subject: [NSIS] QSPEC, QOSMs, QoS NSLP interactions
> 
> 
> I've been following this latest discussion on the QSPEC and 
> QoS NSLP interactions, and state machines. I understand (or I 
> think I do) Dave's comment that QOSMs (or RMF) should not be 
> able to affect the QoS NSLP state machine, and that is a good 
> and valid point.
> 
> Yet, how would e.g. reservation and signaling aggregation 
> (e.g. the mentioned separate signaling session for local 
> domain use), resource pre-emption or the local QSPEC concept 
> work? Don't these in fact change the normal operation of the 
> QoS NSLP at the edges of a special treatment domain?
> 
> Since one of the main purposes of the QSPEC is to allow a QNI 
> to request something e2e, and QNEs along the way MUST commit 
> to that exact request (not downgrading anything, upgrading 
> would be fine, right?) but how they do it is not fixed, 
> doesn't this apply also to the QoS NSLP, so something along
> 
> "The end-to-end semantic and QoS NSLP messaging by the QNI, 
> or any peer QNE MUST BE preserved, and within those bounds a 
> QOSM must operate."
> 
> This means that e.g.,

---

From: <[email-masked]>
Date: Fri, 5 Jan 2007 16:09:33 +0200

Jukka,

I can't really parse the text you have supplied.  Where do you think
such text should be added?

John 

>From: ext Jukka MJ Manner [mailto:[email-masked]] 
>Sent: 05 January, 2007 12:56
>To: [email-masked]
>"The end-to-end semantic and QoS NSLP messaging by the QNI, or 
>any peer QNE MUST BE preserved, and within those bounds a QOSM 
>must operate."
>
>This means that e.g.,

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 5 Jan 2007 16:31:42 +0200 (EET)

John,

I don't really have a direct placeholder for it, but somewhere in both 
QSPEC and QoS NSLP. 

My main point was to get feedback on whether we should relax the NSLP 
messaging and RMF interfactions from their current wording, similarly than 
resource provisioning is not specified, just that it must support the 
QNI's request. A certain domain running a QOSM X can well do certain 
optimizations, incl. separate signaling sessions and aggregation, provided 
that

1) it fulfils the original request of the QNIs, and

2) the end-to-end semantic and the end-to-end QoS NSLP messaging by the 
   QNI, or any peer QNE are preserved.

Within those bounds a QOSM must operate, incl. any domain internal 
optimized signaling.

Jukka

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 5 Jan 2007 08:55:35 -0600

Jukka,

It seems you are not saying another contrary to what John stated as
consensus in his posting at
http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html:

"the QOSM specification SHOULD NOT be allowed to define 'new RMF
functions required by a QOSM' UNLESS such NSIS signaling functionality
is defined in QoS NSLP.  I.e., a QOSM is not allowed to extend QoS NSLP
signaling functionality...new RMF functions are specified only 'within a
QoS NSLP signaling framework'."

Otherwise please clarify.

Thanks,
Jerry

-----Original Message-----
From: Jukka MJ Manner [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 9:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] QSPEC, QOSMs, QoS NSLP interactions

John,

My main point was to get feedback on whether we should relax the NSLP 
messaging and RMF interfactions from their current wording, similarly
than 
resource provisioning is not specified, just that it must support the 
QNI's request. A certain domain running a QOSM X can well do certain 
optimizations, incl. separate signaling sessions and aggregation,
provided 
that

Jukka

---

From: David R Oran <[email-masked]>
Date: Fri, 5 Jan 2007 10:11:22 -0500

> change the normal operation of the QoS NSLP at the edges of a special
Well, this is why I've always viewed priority and preemption as  
really part of the NSLP and not part of the QSPEC.

> QNE MUST BE preserved, and within those bounds a QOSM must operate."
True, and this is one major reason why we changed the design so the  
user could directly control what elements of the QSPEC constituted  
mandatory constraints to be met for admission to succeed.

> c) tear-down must be followed, etc.
All true statements.

Dave.

---

From: David R Oran <[email-masked]>
Date: Fri, 5 Jan 2007 10:13:05 -0500

> or any peer QNE MUST BE preserved, and within those bounds a
I think the constraints are stronger than this, if you want the  
domain-local elements to be able to claim conformance to the QOS NSLP  
specification. If not, the entire argument is moot, since then your  
domain-local signaling is completely proprietary and non-standard.

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 5 Jan 2007 18:53:08 +0200 (EET)

Thanks for the confirmation. :)

Jukka

On Fri, 5 Jan 2007, David R Oran wrote:

> Well, this is why I've always viewed priority and preemption as really part of
> the NSLP and not part of the QSPEC.
> 
> True, and this is one major reason why we changed the design so the user could
> directly control what elements of the QSPEC constituted mandatory constraints
> to be met for admission to succeed.
> 
> >This means that e.g.,

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 5 Jan 2007 19:18:51 +0200 (EET)

Hi,

Yes, I think we are talking about the same thing - just wanted to check I 
got the discussion right. 

Still, one of the problems is about what is allowed for a QOSM to do, and 
what is not. What is a "new RMF function" (and what is not)? 

Clearly, separate signaling sessions for local domain use, session 
aggregation, session binding, etc. are all within the bounds.

It would really help if the RMD folks could specify what would break in 
the RMD spec, is there functionality that is currently not included in the 
NSLP or the QSPEC.

Jukka