Subject: RE: [NSIS] Support for local domain information in the QSPEC

From: <[email-masked]>
Date: Mon, 4 Dec 2006 10:46:55 +0200

Hi Jerry,
 
Thanks for the feedback.  Does the working agree?
 
John

________________________________

	From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
	Sent: 30 November, 2006 14:42
	To: Loughney John (Nokia-NRC/Helsinki); [email-masked]
	Cc: Ash, Gerald R (Jerry), ALABS
	Subject: RE: [NSIS] Support for local domain information in the
QSPEC

	Hi John,
	 
	My impression was clearly agreement on option 1, which I think
Georgios originally described in his post at 
	http://www1.ietf.org/mail-archive/web/nsis/current/msg07213.html
	and again at
	http://www1.ietf.org/mail-archive/web/nsis/current/msg07232.html
	 
	On the thread I think most agreed with Georgios' suggestion, see

	http://www1.ietf.org/mail-archive/web/nsis/current/msg07237.html
	and then
	http://www1.ietf.org/mail-archive/web/nsis/current/msg07238.html
	 
	Thanks,
	Jerry

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Thursday, November 30, 2006 2:55 AM
	To: [email-masked]
	Subject: [NSIS] Support for local domain information in the
QSPEC

	I'm trying to tease through all of the mails on this, and so if
my interpretation is incorrect, please suggest corrective text.

	At the previous IETF, Dave Oran proposed that we have a
mathmatically complete description of the traffic source.  I believe we
have consensus on that. 

	The open question is how to handle QoS model specific
parameters: traffic class, diff serv classes, etc. 
	1) Include a common set of them as optional parameters in the
QSPEC document and allow QoSM documents define additional parameters via
an IANA registry.  

	2) Allow QoSM documents to define their own complete QSPECs,
which are used within the QoSM domain, essentially defining an e2e QSPEC
and a local QSPEC.

	I think Georgios summarized these quite well in: 
	http://www1.ietf.org/mail-archive/web/nsis/current/msg07164.html
<http://www1.ietf.org/mail-archive/web/nsis/current/msg07164.html>  

	I believe that more people were favoring #2.  Of course, the
devil is always in the details, as there have been discussions about
what parameters belong where.

	Comments? 
	John 

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 4 Dec 2006 10:34:24 +0100

Hi John

I have the impression that these two options are different than the ones
that we were discussing in the mailing list.

I think that the consensus that we have had until now is described in:

 <http://www1.ietf.org/mail-archive/web/nsis/current/msg07182.html>
http://www1.ietf.org/mail-archive/web/nsis/current/msg07182.html

Thus if I look to the proposal of Dave Oran I think that we need need 

both otion 3 (parallel session support) and option 2, which is 

Rolands proposal that encapsulates end-to-end QSPEC into a 

local QSPEC and gives the possibility to the QoS model 

to specify which QSPEC parameters can be ignored.

Best Regards,

Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 4 december 2006 9:47
To: [email-masked]; [email-masked]
Subject: RE: [NSIS] Support for local domain information in the QSPEC

Hi Jerry,

John

  _____  

Subject: RE: [NSIS] Support for local domain information in the QSPEC

Hi John,
 
My impression was clearly agreement on option 1, which I think Georgios
originally described in his post at 
http://www1.ietf.org/mail-archive/web/nsis/current/msg07213.html
and again at
http://www1.ietf.org/mail-archive/web/nsis/current/msg07232.html

Thanks,
Jerry

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 2:55 AM
To: [email-masked]
Subject: [NSIS] Support for local domain information in the QSPEC

I'm trying to tease through all of the mails on this, and so if my
interpretation is incorrect, please suggest corrective text.

At the previous IETF, Dave Oran proposed that we have a mathmatically
complete description of the traffic source.  I believe we have consensus on
that. 

The open question is how to handle QoS model specific parameters: traffic
class, diff serv classes, etc. 
1) Include a common set of them as optional parameters in the QSPEC document
and allow QoSM documents define additional parameters via an IANA registry.

2) Allow QoSM documents to define their own complete QSPECs, which are used
within the QoSM domain, essentially defining an e2e QSPEC and a local QSPEC.

I believe that more people were favoring #2.  Of course, the devil is always
in the details, as there have been discussions about what parameters belong
where.

Comments? 
John

---

From: Roland Bless <[email-masked]>
Date: Mon, 04 Dec 2006 11:32:00 +0100

Hi John,

> Thanks for the feedback.  Does the working agree?

No. I'm actually slightly confused by Jerry's posting
since this discussion about options 1) and 2)
has nothing to do with the mails he quoted.
The quoted mails refer to the fact that the QSPEC
template draft will contain a general description of
QSPECs (as template for QOSM designers that specify their
on local QSPECs) as well as the e2e QSPEC.

My point is: if a DiffServ class parameter is attached,
the QSPEC type should be different from the generic e2e QSPEC.
So instead of having a QOSM ID we should have a QSPEC ID
with 1 being the generic e2e QSPEC which should be understood
by all QOSMs.

Regards,
 Roland

>     ------------------------------------------------------------------------
>     *From:* ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
>     *Sent:* 30 November, 2006 14:42
>     *To:* Loughney John (Nokia-NRC/Helsinki); [email-masked]
>     *Cc:* Ash, Gerald R (Jerry), ALABS
>     *Subject:* RE: [NSIS] Support for local domain information in the QSPEC
> 
>     Hi John,
>      
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *Sent:* Thursday, November 30, 2006 2:55 AM
>     *To:* [email-masked]
>     *Subject:* [NSIS] Support for local domain information in the QSPEC
> 
>     mathmatically complete description of the traffic source.  I believe
>     we have consensus on that.
> 
>     The open question is how to handle QoS model specific parameters:
>     traffic class, diff serv classes, etc.
>     1) Include a common set of them as optional parameters in the QSPEC
>     document and allow QoSM documents define additional parameters via
>     an IANA registry. 
> 
>     2) Allow QoSM documents to define their own complete QSPECs, which
>     are used within the QoSM domain, essentially defining an e2e QSPEC
>     and a local QSPEC.
> 
>     _http://www1.ietf.org/mail-archive/web/nsis/current/msg07164.html_
> 
>     I believe that more people were favoring #2.  Of course, the devil
>     is always in the details, as there have been discussions about what
>     parameters belong where.
> 
>     Comments?
>     John

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 4 Dec 2006 08:22:21 -0600

Hi Roland, John, and All,

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: Monday, December 04, 2006 5:32 AM
> To: [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: [NSIS] Support for local domain information in the QSPEC
> 
> Hi John,
> 

I thought the question John posed was related to which parameters should
be described in the QSPEC draft and which should be described in QOSM
specifications.  I think we agree on all except <PHB Class>, <DSTE Class
Type>, and <Y.1541 QoS Class>.  I understood Roland to originally
propose that these parameters be described in QOSM specifications rather
than the QSPEC draft.  I understood Georgios to propose that these be
left in the QSPEC draft:

"Jerry could separate the QSPEC template draft into:
A section/part that describes the Token Bucket + constraints. 
This part could then emphasize that the described parameters 
can be used for interoperability purposes.
Another part of the QSPEC template draft will describe 
the other parameters."

I also understood Roland to later agree with Georgios' proposal in his
post:

"However, it's also ok for me to describe both aspects in one document
as it is probably now too late and too disturbing to make this
separation."

Perhaps I misunderstood these suggestions.  If so, please clarify.
 
> with 1 being the generic e2e QSPEC which should be understood

I don't think we have a concept of 'generic QSPEC' in the current
proposal.  Only the TMOD-1 parameter must be populated and must be
interpreted by all QNEs.  All other parameters are optional to populate
and optional to interpret by QNEs (unless marked by the M-flag by the
QNI).

Thanks,
Regards,
Jerry

> >     mathematically complete description of the traffic 
> >     source.  I believe

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 4 Dec 2006 16:36:39 +0100

Hi Jerry

The question of John was related to another issue.
It was related to the e-mails posted by Dave Oran and 
Roland regarding the stacking issue.

I think that the consensus that we have had until now regarding this issue 
is described in:

Both option 3 (parallel session support) and option 2, which is 
Rolands proposal that encapsulates end-to-end QSPEC into a 
local QSPEC and gives the possibility to the QoS model 
to specify which QSPEC parameters can be ignored need to be supported

Best Regards,
Georgios

> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: maandag 4 december 2006 15:22
> To: Roland Bless; [email-masked]
> > No. I'm actually slightly confused by Jerry's posting since this 
> > discussion about options 1) and 2) has nothing to do with 
> the mails he 
> > quoted.
> > The quoted mails refer to the fact that the QSPEC template 
> draft will 
> > contain a general description of QSPECs (as template for QOSM 
> > designers that specify their on local QSPECs) as well as the e2e 
> > QSPEC.
> 
> I thought the question John posed was related to which 
> parameters should be described in the QSPEC draft and which 
> should be described in QOSM specifications.  I think we agree 
> on all except <PHB Class>, <DSTE Class
> propose that these parameters be described in QOSM 
> specifications rather than the QSPEC draft.  I understood 
> Georgios to propose that these be left in the QSPEC draft:
> 
> Another part of the QSPEC template draft will describe the 
> other parameters."
> 
> "However, it's also ok for me to describe both aspects in one 
> document as it is probably now too late and too disturbing to 
> make this separation."
> 
> > My point is: if a DiffServ class parameter is attached, the 
> QSPEC type 
> > should be different from the generic e2e QSPEC.
> with 1 being 
> > the generic e2e QSPEC which should be understood by all QOSMs.
> 
> I don't think we have a concept of 'generic QSPEC' in the 
> current proposal.  Only the TMOD-1 parameter must be 
> populated and must be interpreted by all QNEs.  All other 
> parameters are optional to populate and optional to interpret 
> by QNEs (unless marked by the M-flag by the QNI).
> 
> Thanks,
> Regards,
> Jerry
> 
> > 
> > Regards,
> >  Roland
> > 
> > >

---

From: <[email-masked]>
Date: Mon, 4 Dec 2006 15:00:33 +0200

>From your mail, Georgios's mail and Jerry's mail - I am not sure if we
all have agreed or not on the role(s) of the QSPEC & the QoS NSLP.

If we have an e2e QSPEC and a local QSPEC, then I think the QoS NSLP
will need to manage how to push & pop the local QSPEC, correct?

I think we would need to specify the following behaviors:

1) e2e QSPEC vs. other QSPEC
2) How the QoS NSLP manages the interaction between these two
3) How the e2e QSPEC and the 'other' QSPEC relate to each other,
   which is manditory to support, which is optional, what to do
   if the e2e QSPEC and the other QSPEC contradict each other.

John 

>From: ext Roland Bless [mailto:[email-masked]] 
>Sent: 04 December, 2006 12:32
>To: Loughney John (Nokia-NRC/Helsinki)
>Cc: [email-masked]; [email-masked]
>No. I'm actually slightly confused by Jerry's posting since 
>this discussion about options 1) and 2) has nothing to do with 
>the mails he quoted.
>draft will contain a general description of QSPECs (as 
>template for QOSM designers that specify their on local 
>QSPECs) as well as the e2e QSPEC.
>
>QSPEC type should be different from the generic e2e QSPEC.
>So instead of having a QOSM ID we should have a QSPEC ID with 
>1 being the generic e2e QSPEC which should be understood by all QOSMs.
>
>Regards,
> Roland
>
>>     
>>     *Subject:* RE: [NSIS] Support for local domain 
>information in the 
>> QSPEC
>> 
>>     Hi John,
>>

---

From: Roland Bless <[email-masked]>
Date: Mon, 04 Dec 2006 17:58:58 +0100

Hi John,

> will need to manage how to push & pop the local QSPEC, correct?

No. This is what can be solved by having only one QSPEC object conveyed
by the QoS NSLP: either it's a local (or QOSM specific) QSPEC or the
e2e QSPEC. One way to add local parameters is to define a local QSPEC
that encapsulates the e2e QSPEC and contains also parameters that are
relevant locally only. The QoSM defines how this is exactly done. What
must be ensured is that the QoSM understands the e2e QSPEC, i.e.
gets an e2e QSPEC as input, may create its local QSPEC (which
encapsulates the e2e QSPEC) and emits an e2e QSPEC at the egress to
the next domain again. By using this approach, each QOSM can define
what to do with the original e2e QSPEC (e.g. ignore in internal
routers etc.). There is also no need for push & pop.

> 1) e2e QSPEC vs. other QSPEC

I would allow both, though other QSPECs must maintain the semantics
of the e2e QSPEC (output must be e2e QSPEC at the egress).

> 2) How the QoS NSLP manages the interaction between these two

No, in my proposal the QOS NSLP doesn't deal with any QSPEC,
it simply delivers exactly one QSPEC object to the RMF and
gets exactly one QSPEC object from it (usually the local QSPEC
will encapsulate the e2e QSPEC to fulfill the above requirement)

>    if the e2e QSPEC and the other QSPEC contradict each other.

Each QOSM that needs a local QSPEC should define a mapping
from the e2e QSPEC to its own local parameters, e.g. QoS classes.
The ingress node will create a local QSPEC (if needed at all)
and populate the QoS class parameter, adapt the available QoS
parameters in the e2e QSPEC and encapsulate it in the local QSPEC.
The egress node will terminate the local QSPEC and extract the
encapsulated e2e QSPEC for further forwarding then.

Regards,
 Roland

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 4 Dec 2006 11:23:23 -0600

> >    which is mandatory to support, which is optional, what to do

> encapsulated e2e QSPEC for further forwarding then.

Recall that in the current proposal, the concept of 'remapping' QSPEC
parameters, e.g., from QSPEC parameter 1 to QSPEC parameter 2, is
eliminated.  

A local QSPEC may re-define the same QSPEC parameter in the initiator
QSPEC to an equivalent parameter, e.g., RMD may redefine the TMOD
parameter to an equivalent TMOD parameter that specifies only the peak
rate (i.e., set r=p, b/m to default values). 

Also specified in the current proposal:
- edge nodes must interpret initiator QSPEC parameters
- local QSPEC must be consistent with initiator QSPEC

Thanks,
Regards,
Jerry

---

From: <[email-masked]>
Date: Mon, 4 Dec 2006 22:24:40 +0200

Hi Jerry,

>> Each QOSM that needs a local QSPEC should define a mapping from the 
>> e2e QSPEC to its own local parameters, e.g. QoS classes.
>> The ingress node will create a local QSPEC (if needed at all) and 
>> populate the QoS class parameter, adapt the available QoS parameters 
>> in the e2e QSPEC and encapsulate it in the local QSPEC.
>Recall that in the current proposal, the concept of 
>'remapping' QSPEC parameters, e.g., from QSPEC parameter 1 to 
>QSPEC parameter 2, is eliminated.  
>
>A local QSPEC may re-define the same QSPEC parameter in the 
>initiator QSPEC to an equivalent parameter, e.g., RMD may 
>redefine the TMOD parameter to an equivalent TMOD parameter 
>that specifies only the peak rate (i.e., set r=p, b/m to 
>default values). 
>

Thanks for this, I think these considerations make sense.
Have you drafted text for QSPEC document that covers this?

thanks,
John

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 4 Dec 2006 14:36:12 -0600

Hi John, 

> Sent: Monday, December 04, 2006 3:25 PM
> To: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Cc: [email-masked]
> >> from the 

Yes, the updated text reflects the agreements made at IETF-67 and
subsequently on the list.  The updated QSPEC document is currently under
review by the co-editors, and I hope to submit the update to the I-D
editor later this week.

Thanks,
Jerry

---

From: <[email-masked]>
Date: Mon, 4 Dec 2006 22:45:26 +0200

Hi Jerry,

>Yes, the updated text reflects the agreements made at IETF-67 
>and subsequently on the list.  The updated QSPEC document is 
>currently under review by the co-editors, and I hope to submit 
>the update to the I-D editor later this week.

Good, having text helps.  Reviewing the email threads was a bit
unclear, because there were some places where it appeared that
people were agreeing to different things, and so forth.
 
thanks,
John

---

From: Roland Bless <[email-masked]>
Date: Thu, 07 Dec 2006 09:18:26 +0100

Hi Jerry,

> parameters, e.g., from QSPEC parameter 1 to QSPEC parameter 2, is

I guess that this "Remapping" is different from what I described.
QoS mapping (not remapping) is required at some stage of the admission
control process, i.e. you must decide into which QoS class this
reservation will be put.

> rate (i.e., set r=p, b/m to default values). 

Yes, but it should not alter the original QSPEC parameters
that were specified by the QNE (except in the QoS available
section).

> - local QSPEC must be consistent with initiator QSPEC

Yep. Sounds good at a first glance.
 Roland

---

From: <[email-masked]>
Date: Thu, 7 Dec 2006 10:25:27 +0200

Roland,

>QoS mapping (not remapping) is required at some stage of the 
>admission control process, i.e. you must decide into which QoS 
>class this reservation will be put.
>

>that were specified by the QNE (except in the QoS available section).
>

I agree.  If I used 'remapping' then it was a mistake. What I meant
was mapping the expected e2e qos to the local domain qos, for eaxmple
as you mention deciding what local QoS class the reservation should
be put in.

John