Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 10 Oct 2006 04:16:38 -0500

Lars,

> You mention in the below e-mail that there are no open issues,
> while there is a huge discussion on the nsis mailing list
> regarding the QSPEC-1 parameters.

John can call a different consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion. 
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion. 

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 10 Oct 2006 11:23:19 +0200

Hi Jerry

But any time that someone has another opinion than yours
then the only argument that you give is that this person restarts 
a closed discussion. For example, the QSPEC-1 issues emphasized by Jukka!

Best Regards,
Georgios

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: dinsdag 10 oktober 2006 11:17
> To: Lars Westberg
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt
> 
> Lars,
> 
> > You mention in the below e-mail that there are no open 
> issues, while 
> > there is a huge discussion on the nsis mailing list regarding the 
> > QSPEC-1 parameters.
> 
> John can call a different consensus if he sees one (I've 
> asked him a couple of times to do that).  What I saw was
> 
> 1. Many posts supported the QSPEC-1 concept, only one (or 
> maybe two) I saw opposed.  The opposing view was repeated 
> *many* times (and is still being repeated) but it only counts 
> as one opinion. 
> 2. Many posts supported retaining the 4 QSPEC-1 parameters, 
> only one I saw opposed.  The opposing view was repeated many times.
> 3. There was only one opinion expressed to be able to ignore 
> QSPEC-1 parameters.  That one opinion has been repeated many 
> times but it only counts as one opinion. 
> 
> John asked a while ago for new opinions on these issues, that 
> would be good if there are any *new* opinions.  We don't need 
> to hear opinions repeated that we've seen so many times.
> 
> I invite John once again to make a consensus call so we can 
> move on here.  I think it is time to make progress and stop 
> repeating ourselves, we're not generating any new light in 
> this rather endless discussion.
> 
> Thanks,
> Jerry
>

---

From: Lars Westberg <[email-masked]>
Date: Mon, 16 Oct 2006 11:51:37 +0200

Hi,
 The template seems not to be a template because the mandatory part  is 
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that 
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate 
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 08:29:10 +0200 (MEST)

Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?

Best Regards,
Georgios

---

From: Lars Westberg <[email-masked]>
Date: Tue, 17 Oct 2006 08:45:36 +0200

yes.
the main problem is that IETF is not the only Standardization 
organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs 
specified by MEF????

How can we use it for 3GPP-Qos definitiions ?

In the draft I also see  that we the draft specify a new bearer service. 
It is not compliant to old Int.serv architecture.  This is a completely 
new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the 
"optimal"-set of parameters.

I think we agree in beggining the working group discussion that we 
should not specify any "bearer-service" because NSIS should be a modular 
architecture with  more flexibillity than RSVP.  Therefore, I am 
surprised that we are doing the same mistake as in RSVP: Integrating a 
bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in 
this case significantly better in terms of performance and have the same 
functionality than NSIS.
If have to choose I would select RSVP rather than a much more complex  
three layer protocol stack.

regards Lasse

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 17 Oct 2006 10:28:08 +0200

Hi Lars, 
 
could you explain why the qspec draft defines a new bearer service? 
 
What is a bearer service? This concept exists in 3GPP, but it does not
exist in IETF I dont think, and I dont think the 3GPP definition is
transferrable to IETF. So what exactly are you stating?
 
Cornelia

________________________________

	Von: Lars Westberg [mailto:[email-masked]] 
	Gesendet: Dienstag, 17. Oktober 2006 08:46
	An: Georgios Karagiannis
	Cc: [email-masked]; [email-masked]
	Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

	yes. 
	the main problem is that IETF is not the only Standardization
organization that like to discuss "bearer services". Just as an example
:
	If we specify the those parameters, How can we use NSIS for SLAs
specified by MEF????

	In the draft I also see  that we the draft specify a new bearer
service. It is not compliant to old Int.serv architecture.  This is a
completely new one with new parameters like priority.

	I think we agree in beggining the working group discussion that
we should not specify any "bearer-service" because NSIS should be a
modular architecture with  more flexibillity than RSVP.  Therefore, I am
surprised that we are doing the same mistake as in RSVP: Integrating a
bearer service definition into the NSIS-architecture.
	
	If we go this track, the QoS-part of NSIS has much less use.
RSVP is in this case significantly better in terms of performance and
have the same functionality than NSIS.
	If have to choose I would select RSVP rather than a much more
complex  three layer protocol stack.
	
	regards Lasse

		Hi Lars
		
		Do you mean that the QSPEC template must not contain any
mandatory
		(QSPEC-1) parameters?

		Best Regards,
		Georgios

		On 10/16/2006, "Lars Westberg"
<[email-masked]> <mailto:[email-masked]>  wrote:

			Hi,
			The template seems not to be a template because
the mandatory part  is
			more or less the same as Intserv.
			The main idea with QoS-template was to make an
modular solution that
			could allow flexibillity for different
Qos-models
			
			Therefore, I do not understand the scope of the
specification.
			
			I suggest that we move the major part of the
parameters to a separate
			"Int.serv. over NSIS" specification.
			Int.serv. can be seen as a common bearer
service.
			
			regards Lasse

				Lars,

				You mention in the below e-mail that
there are no open issues,
				while there is a huge discussion on the
nsis mailing list
				regarding the QSPEC-1 parameters.

				John can call a different consensus if
he sees one (I've asked him a
				couple of times to do that).  What I saw
was
				
				1. Many posts supported the QSPEC-1
concept, only one (or maybe two) I
				saw opposed.  The opposing view was
repeated *many* times (and is still
				being repeated) but it only counts as
one opinion.
				2. Many posts supported retaining the 4
QSPEC-1 parameters, only one I
				saw opposed.  The opposing view was
repeated many times.
				3. There was only one opinion expressed
to be able to ignore QSPEC-1
				parameters.  That one opinion has been
repeated many times but it only
				counts as one opinion.
				
				John asked a while ago for new opinions
on these issues, that would be
				good if there are any *new* opinions.
We don't need to hear opinions
				repeated that we've seen so many times.
				
				I invite John once again to make a
consensus call so we can move on
				here.  I think it is time to make
progress and stop repeating ourselves,
				we're not generating any new light in
this rather endless discussion.
				
				Thanks,
				Jerry

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 17 Oct 2006 10:35:56 +0200

Hi Lars, 
 
what you call "mandatory" does _overlap_ with IntServ because this was
the WG requirement when we started the QSPEC work. If the WG removes
this requirement we can remove these parameter(s).
 
Note that we in fact included just _one_ out of about six IntServ
parameters, namely the Token Bucket. Most IntServ paras (C_tot, D_tot, S
etc) are not included (at least not in the interesting qspec-1 parameter
category). 
 
So anyway I dont think your statement is correct.
 
Cornelia

	Von: Lars Westberg [mailto:[email-masked]] 
	Gesendet: Montag, 16. Oktober 2006 11:52
	An: Ash, Gerald R (Jerry), ALABS; [email-masked]
	Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

	Hi,
	 The template seems not to be a template because the mandatory
part  is more or less the same as Intserv.
	The main idea with QoS-template was to make an modular solution
that could allow flexibillity for different Qos-models

	I suggest that we move the major part of the parameters to a
separate "Int.serv. over NSIS" specification.
	Int.serv. can be seen as a common bearer service.
	
	regards Lasse

		Lars,
		
		> You mention in the below e-mail that there are no open
issues,
		
asked him a
		
		1. Many posts supported the QSPEC-1 concept, only one
(or maybe two) I
		saw opposed.  The opposing view was repeated *many*
times (and is still
		being repeated) but it only counts as one opinion.
		2. Many posts supported retaining the 4 QSPEC-1
parameters, only one I
		saw opposed.  The opposing view was repeated many times.
		3. There was only one opinion expressed to be able to
ignore QSPEC-1
		parameters.  That one opinion has been repeated many
times but it only
		counts as one opinion.
		
		John asked a while ago for new opinions on these issues,
that would be
		good if there are any *new* opinions.  We don't need to
hear opinions
		repeated that we've seen so many times.
		
		I invite John once again to make a consensus call so we
can move on
		here.  I think it is time to make progress and stop
repeating ourselves,
		we're not generating any new light in this rather
endless discussion.
		
		Thanks,
		Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 10:40:10 +0200

Hi Lars
 
I think that I agree with you!
 
However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket
and Bandwidth) 
that can be mandatory. In this way we will provide the required
interoperability between the 
QoS models.
Actually this was also the conclusion that Xiaoming deduced after studying a
couple of examples.
 
Furthermore, we could however provide the ability to QoS models to specify
which 
QSPEC parameters should be mandatory or not.
What do you think?
 
Best regards,
Georgios

  _____  

From: Lars Westberg [mailto:[email-masked]] 
Sent: dinsdag 17 oktober 2006 8:46
To: Georgios Karagiannis
Cc: [email-masked]; [email-masked]
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

yes. 
the main problem is that IETF is not the only Standardization organization
that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs specified
by MEF????

In the draft I also see  that we the draft specify a new bearer service. It
is not compliant to old Int.serv architecture.  This is a completely new one
with new parameters like priority.

I think we agree in beggining the working group discussion that we should
not specify any "bearer-service" because NSIS should be a modular
architecture with  more flexibillity than RSVP.  Therefore, I am surprised
that we are doing the same mistake as in RSVP: Integrating a bearer service
definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in this
case significantly better in terms of performance and have the same
functionality than NSIS.
If have to choose I would select RSVP rather than a much more complex  three
layer protocol stack.

regards Lasse

Hi Lars

(QSPEC-1) parameters?

Best Regards,

Georgios

On 10/16/2006, "Lars Westberg"  <mailto:[email-masked]>
<[email-masked]> wrote:

Hi,

regards Lasse

    

Lars,

counts as one opinion.

Thanks,

Jerry

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Tue, 17 Oct 2006 10:51:47 +0200

let's try to understand my concern. 
 
During years, many people have spend a huge set of effort on Qos.
Especially specification of parameters and the outcome resulted in
"over"-specified definitions.
 
We will se many operators that trying to specify SLA:s of different
kinds and they will have their own opinion. These SLAs may not be
end-2-end within Internet like MEF but instead used for specific use.
With this concept with a specified bearer service, noone can apply a new
concept without having the overhead of the mandatory specification. 
 
The major problem is that NSIS building exactly the same architecture as
RSVP based on the assumption that everything has to be equal. So, what
is the gain with NSIS ?????
Where is the flexibillity ????
 
How can we handle other standards bodies if they would like to have
their own specification ?
if you can't use the flexibillity, the answer is that they will develop
their own QoS-signalling.
 
I think it is very important to let the Qos-template to become a
template and not a "beaer-service" specification. We have a lot of
optional parameters that should be moved from the specification, because
that is also causing the confusion.
 
I suggest that we have one encapsulation of controlled based on the
previous RFCs and not specify new objects. This Controlled Load can be
used for end-2-end interoperabillity but should not be mandatory.

regards Lasse

From: Kappler, Cornelia [mailto:[email-masked]] 
Sent: den 17 oktober 2006 10:28
To: Lars Westberg (KI/EAB); Georgios Karagiannis
Cc: [email-masked]; [email-masked]
Subject: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Hi Lars, 

 
Cornelia

	yes. 

	

	
	regards Lasse

		Hi Lars

		Best Regards,
		Georgios

			Hi,

			
			regards Lasse

				Lars,

				

				
				Thanks,
				Jerry

---

From: Lars Westberg <[email-masked]>
Date: Tue, 17 Oct 2006 10:55:46 +0200

comments inline

> could you explain why the qspec draft defines a new bearer service?

let's define it as "Specification of the Controlled-Load Network Element 
Service"
=>a specifiaction of treatment of a "flow".

> transferrable to IETF. So what exactly are you stating?

see above.

> Cornelia
>
>     ------------------------------------------------------------------------
>     service. It is not compliant to old Int.serv architecture.  This
>     is a completely new one with new parameters like priority.
>
>     should not specify any "bearer-service" because NSIS should be a
>     modular architecture with  more flexibillity than RSVP. 
>     Therefore, I am surprised that we are doing the same mistake as in
>     RSVP: Integrating a bearer service definition into the
>     NSIS-architecture.
>
>     If we go this track, the QoS-part of NSIS has much less use. RSVP
>     is in this case significantly better in terms of performance and

---

From: Lars Westberg <[email-masked]>
Date: Tue, 17 Oct 2006 11:23:22 +0200

first of all, the specification defines a lot of parameters that have 
never ben discussed in Int-serv (not as far as I know) like Priority. I 
do not know about any of these in the history of Controlled Load. All of 
these parameters can be put in another specification.

the DSCP is not a part of IntServ-architecture because is is added 
afterwards. If we should add those, why not re-use the DCLASS-object???
Why specify a new one ????

I am confused. We are re-specifying objects for something that have 
already been specified before and we insert new parameters that make the 
specification les usefull in other context. I thought that NSIS should 
be applicable for future use where RSVP can not handle the modularity.

I suggest that we divide the template into two parts: one template and 
one specification for "IntServ over NSIS".
If this is not be done, I do not see how we can handle 
Metroethernetforums parameters set in MEF7.
check http://www.metroethernetforum.org/TechSpec.htm.

regards Lasse
Kappler, Cornelia wrote:

> parameters, namely the Token Bucket. Most IntServ paras (C_tot, D_tot, 
> S etc) are not included (at least not in the interesting qspec-1 
> parameter category).
>  
>>     would be

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 17 Oct 2006 11:57:13 +0200

Hi Lasse,
 
"specification of treatment of a flow" should be done in the QOSM Specs
(e.g. RMD, CLS), it is not at an issue of the QSPEC. 
 
The job of the QSPEC draft is to define a set of parameters that QOSM
specs can choose from to define this treatment. (Would you agree this is
a reasonable approach?)
 
Could you more concretely point out where in the QSPEC a specific flow
treatment is defined - beyond the (necessary) description of  how a
particular parameter should be dealt with?
 
Cornelia

	Von: Lars Westberg [mailto:[email-masked]] 
	Gesendet: Dienstag, 17. Oktober 2006 10:56
	An: Kappler, Cornelia
	Cc: Georgios Karagiannis; [email-masked]; [email-masked]
	Betreff: Re: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

	comments inline
	
	Kappler, Cornelia wrote:

		Hi Lars, 
		 
		could you explain why the qspec draft defines a new
bearer service? 

	let's define it as "Specification of the Controlled-Load Network
Element Service"
	=>a specifiaction of treatment of a "flow". 

		What is a bearer service? This concept exists in 3GPP,
but it does not exist in IETF I dont think, and I dont think the 3GPP
definition is transferrable to IETF. So what exactly are you stating?

	see above. 

		Cornelia

			Von: Lars Westberg
[mailto:[email-masked]] 
			Gesendet: Dienstag, 17. Oktober 2006 08:46
			An: Georgios Karagiannis
			Cc: [email-masked]; [email-masked]
			Betreff: Re: [NSIS] I-D
ACTION:draft-ietf-nsis-qspec-12.txt

			yes. 
			the main problem is that IETF is not the only
Standardization organization that like to discuss "bearer services".
Just as an example :
			If we specify the those parameters, How can we
use NSIS for SLAs specified by MEF????

			In the draft I also see  that we the draft
specify a new bearer service. It is not compliant to old Int.serv
architecture.  This is a completely new one with new parameters like
priority.
			
			I can sure that we can have a never-ending
discussion about the "optimal"-set of parameters.
			
			I think we agree in beggining the working group
discussion that we should not specify any "bearer-service" because NSIS
should be a modular architecture with  more flexibillity than RSVP.
Therefore, I am surprised that we are doing the same mistake as in RSVP:
Integrating a bearer service definition into the NSIS-architecture.
			
			If we go this track, the QoS-part of NSIS has
much less use. RSVP is in this case significantly better in terms of
performance and have the same functionality than NSIS.
			If have to choose I would select RSVP rather
than a much more complex  three layer protocol stack.
			
			regards Lasse

				Hi Lars
				
				Do you mean that the QSPEC template must
not contain any mandatory
				(QSPEC-1) parameters?

				Best Regards,
				Georgios

				Hi,
				The template seems not to be a template
because the mandatory part  is
				more or less the same as Intserv.
				The main idea with QoS-template was to
make an modular solution that
				could allow flexibillity for different
Qos-models
				
				Therefore, I do not understand the scope
of the specification.
				
				I suggest that we move the major part of
the parameters to a separate
				"Int.serv. over NSIS" specification.
				Int.serv. can be seen as a common bearer
service.
				
				regards Lasse

				Lars,

				

				
				Thanks,
				Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 14:23:43 +0200

Hi Cornelia
 
What Lars means is that when the QSPEC template defines that 
Traffic, QoS Class, Excess Treatment and Priority are mandatory sets of
parameters
then the QS{PEC template is also defining a bearer service. 
Meaning that all QNEs must support these parameters, thus they 
must support the bearer service that is dictated by the 4 sets of mandatory
parameters, i.e., 13 mandatory parameters.
 
It is very important to note that there are not 4 mandatory parameters but
there are 4 sets of mandatory parmeters.
The total number of mandatory parameters is 13.
 
* Traffic parameter set has 2 mandatory parameters
* QoS class set has 3 mandatory parameters
* Priority has 4 mandatory parameters
* Excess Treatment has 4 mandatory parameters

Best Regards,
Georgios

  _____  

From: Kappler, Cornelia [mailto:[email-masked]] 
Sent: dinsdag 17 oktober 2006 11:57
To: Lars Westberg
Cc: [email-masked]; Georgios Karagiannis; [email-masked]
Subject: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Hi Lasse,

The job of the QSPEC draft is to define a set of parameters that QOSM specs
can choose from to define this treatment. (Would you agree this is a
reasonable approach?)

Cornelia

  _____  

comments inline

Kappler, Cornelia wrote:

Hi Lars, 

What is a bearer service? This concept exists in 3GPP, but it does not exist
in IETF I dont think, and I dont think the 3GPP definition is transferrable
to IETF. So what exactly are you stating?

see above. 

Cornelia

  _____  

yes. 

regards Lasse

Hi Lars

(QSPEC-1) parameters?

Best Regards,

Georgios

  

Hi,

regards Lasse

    

Lars,

counts as one opinion.

Thanks,

Jerry

---

From: Lars Westberg <[email-masked]>
Date: Tue, 17 Oct 2006 14:32:46 +0200

The specification of Qspec1 is mandatory and therefore as I can see can 
not be avoided and
The parameter description in The Qspec-1 is more detalied than  Int.serv.
The reason for dividing NSIS in three layers was that Int.serv.  was too 
tightly built-into RSVP.
Now, I see that this benefit is gone and what's the gain with NSIS for QoS ?

If one just read the specification, and compare it with Int.serv. oe can 
conclude the following:
1) More parameters than Intserv. (excess treatment, priority???)
2) More functionality required for implementation even if its never used.

issues like :
how to model MEF bearer service definition ?????

...more layers with more functionality in each layer stacked on each 
other. I do not know what to do.....

regards Lasse

Kappler, Cornelia wrote:

> Hi Lasse,
>  
> "specification of treatment of a flow" should be done in the QOSM 
> Specs (e.g. RMD, CLS), it is not at an issue of the QSPEC.
>  
> specs can choose from to define this treatment. (Would you agree this 
> is a reasonable approach?)
>  

if the collection of paramters does not limit the applicabillity of 
QoS-models that may be ok.

> particular parameter should be dealt with?

I have sent out pointer to Metro-Ethernet forum specification.

>>     What is a bearer service? This concept exists in 3GPP, but it
>>     does not exist in IETF I dont think, and I dont think the 3GPP
>>         If we specify the those parameters, How can we use NSIS for
>>         SLAs specified by MEF????
>>
>>         In the draft I also see  that we the draft specify a new
>>         bearer service. It is not compliant to old Int.serv
>>         architecture.  This is a completely new one with new
>>         parameters like priority.
>>
>>         I can sure that we can have a never-ending discussion about
>>         the "optimal"-set of parameters.
>>
>>         I think we agree in beggining the working group discussion
>>         that we should not specify any "bearer-service" because NSIS
>>         should be a modular architecture with  more flexibillity than
>>         RSVP.  Therefore, I am surprised that we are doing the same
>>         mistake as in RSVP: Integrating a bearer service definition
>>         into the NSIS-architecture.
>>
>>         RSVP is in this case significantly better in terms of

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 15:44:44 +0200

Hi Lars
 
So, what you actually say is that it would be quite impossible to 
deploy NSIS based QoS  solutions in e.g., 3GPP or MEF (Metro-Ethernet
Forum), if 
the QSEPC template draft specifies the use of
any mandatory (QSPEC-1) parameters.
 
Best Regards,
Georgios

 

  _____  

From: Lars Westberg [mailto:[email-masked]] 
Sent: dinsdag 17 oktober 2006 14:33
To: Kappler, Cornelia
Cc: Georgios Karagiannis; [email-masked]; [email-masked]
Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

The specification of Qspec1 is mandatory and therefore as I can see can not
be avoided and
The parameter description in The Qspec-1 is more detalied than  Int.serv.
The reason for dividing NSIS in three layers was that Int.serv.  was too
tightly built-into RSVP. 
Now, I see that this benefit is gone and what's the gain with NSIS for QoS ?

issues like :

...more layers with more functionality in each layer stacked on each other.
I do not know what to do.....

regards Lasse

Kappler, Cornelia wrote:

Hi Lasse,

 
Cornelia

  _____  

comments inline

Kappler, Cornelia wrote:

Hi Lars, 

see above. 

Cornelia

  _____  

yes. 

regards Lasse

Hi Lars

(QSPEC-1) parameters?

Best Regards,

Georgios

  

Hi,

regards Lasse

    

Lars,

counts as one opinion.

Thanks,

Jerry

---

From: <[email-masked]>
Date: Tue, 17 Oct 2006 16:45:21 +0300

There was a proposal for a QoS model on 3GPP QoS model, by the way.
http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt
 
However, I think that we are going circular.  The QSPEC defines a
general model for being able to support different QoS Models.  We were
asked to look at how to support different models, including Y1541, by
our AD at the time and by ITU-T liasons.
 
If you feel that things are too complicated, I would suggest you send a
list of what you consider to be mandatory and what is optional (or in
otherwords, what is essential and what is not).  It could be that we
have created something that is more complicated than what is generally
needed, but then we need a counter proposal.
 
thanks,
John

	From: ext Lars Westberg [mailto:[email-masked]] 
	Sent: 16 October, 2006 23:46
	To: Georgios Karagiannis
	Cc: [email-masked]; [email-masked]
	Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

	yes. 

	

	
	regards Lasse

		Hi Lars

		Best Regards,
		Georgios

			Hi,

			
			regards Lasse

				Lars,

				

				
				Thanks,
				Jerry

---

From: <[email-masked]>
Date: Tue, 17 Oct 2006 16:45:21 +0300

thanks,
John

	yes. 

	

	
	regards Lasse

		Hi Lars

		Best Regards,
		Georgios

			Hi,

			
			regards Lasse

				Lars,

				

				
				Thanks,
				Jerry

---

From: <[email-masked]>
Date: Tue, 17 Oct 2006 17:20:37 +0300

Georgios,
 
About having the QoS Models specifying manditory parameters - could you
explain how we would get interoperability between two different QoS
models that have different sets of manditory parameters?
 
I think we need to have a baseline QSPEC with manditory parameters to
ensure interoperability - we should have the lowest common denominator
between the QoS models to ensure some way of being able to signal across
multiple QoS model deployments.
 
John

	From: ext Georgios Karagiannis [mailto:[email-masked]] 
	Sent: 17 October, 2006 01:40
	To: 'Lars Westberg'
	Cc: [email-masked]; [email-masked]
	Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

	Hi Lars

	However, we may just need one QSPEC parameter, say Traffic
(Tocken Bucket and Bandwidth) 
	that can be mandatory. In this way we will provide the required
interoperability between the 
	QoS models.
	Actually this was also the conclusion that Xiaoming deduced
after studying a couple of examples.
	 
	Furthermore, we could however provide the ability to QoS models
to specify which 
	QSPEC parameters should be mandatory or not.
	What do you think?
	 
	Best regards,
	Georgios

		Subject: Re: [NSIS] I-D

		yes. 
		the main problem is that IETF is not the only
Standardization organization that like to discuss "bearer services".
Just as an example :
		If we specify the those parameters, How can we use NSIS
for SLAs specified by MEF????

		In the draft I also see  that we the draft specify a new
bearer service. It is not compliant to old Int.serv architecture.  This
is a completely new one with new parameters like priority.
		
		I can sure that we can have a never-ending discussion
about the "optimal"-set of parameters.

		If we go this track, the QoS-part of NSIS has much less
use. RSVP is in this case significantly better in terms of performance
and have the same functionality than NSIS.
		If have to choose I would select RSVP rather than a much
more complex  three layer protocol stack.
		
		regards Lasse

			Hi Lars
			
			Do you mean that the QSPEC template must not
contain any mandatory
			(QSPEC-1) parameters?

			Best Regards,
			Georgios

				Hi,

				
				regards Lasse

				Lars,

				

				
				Thanks,
				Jerry

---

From: Lars Westberg <[email-masked]>
Date: Tue, 17 Oct 2006 16:45:16 +0200

comments inline

> our AD at the time and by ITU-T liasons.

The QSPEC-template at that time, defined an generic format for Qspec. 
The problem is that the draft contain a mandatory model that make it 
impossible to use the flexibillity i.e. MEF-definitions.

Don't you remeber the discussion of the three layer model ??????????
The major reason was to get a more open and modular architecture.

We have now developped the same architectue again but have specified in 
such away only controlled load can be used.  It is even worse, we can 
not support GQS in our model, so the flexibillity is more limited than 
RSVP ???????????????????????????

I am still very confused...............

regards Lasse

>  
> If you feel that things are too complicated, I would suggest you send 
> a list of what you consider to be mandatory and what is optional (or 
> in otherwords, what is essential and what is not).  It could be that 
> we have created something that is more complicated than what is 
> generally needed, but then we need a counter proposal.

I do already.

The

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 16:51:00 +0200

Hi John
 
A solution of this can be as follows.
 
First of all: the QSPEC template does not specify  mandatory parameters.
 
However, an end-to-end QoS model may mandate the use of a QSPEC parameter. 
Any QNE that suopports this end-to-end QoS model then it will have to
interpret 
(strictly or remap) this parameter. The remapping is then specified in the
end -to-end QOSM draft.
 
Another local QoS model that needs to interoperate with the end-to-end QoS
model it will either 
have to strictly interpret the parameter specified by the end -to- end QoS
model, or to remap it. 
The remapping is also specified in the local QOSM draft.
 
However, if a QNE does not support the end-to-end QoS model then it will
just set the 
NON-QOSM Hop flag. 
In this way we achieve both modularity and interoperability.
 
Best Regards,
Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 17 oktober 2006 16:21
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Georgios,
 
About having the QoS Models specifying manditory parameters - could you
explain how we would get interoperability between two different QoS models
that have different sets of manditory parameters?
 
I think we need to have a baseline QSPEC with manditory parameters to ensure
interoperability - we should have the lowest common denominator between the
QoS models to ensure some way of being able to signal across multiple QoS
model deployments.
 
John

  _____  

Hi Lars

 
 
Best regards,
Georgios

  _____  

yes. 

regards Lasse

Hi Lars

(QSPEC-1) parameters?

Best Regards,

Georgios

  

Hi,

regards Lasse

    

Lars,

counts as one opinion.

Thanks,

Jerry

---

From: Lars Westberg <[email-masked]>
Date: Tue, 17 Oct 2006 16:52:41 +0200

Once again, you are making the same statement. A service defintion can 
not be future proof. there are no such definitions.
We seen during 15 years of experience from ATM,FR, Int.serv. and MEF and 
3GPP-Qos that different definition has come and go.

[email-masked] wrote:

> Georgios,
>  
> About having the QoS Models specifying manditory parameters - could 
> you explain how we would get interoperability between two different 
> QoS models that have different sets of manditory parameters?
>  

> between the QoS models to ensure some way of being able to signal 
> across multiple QoS model deployments.
>  

Why should we have NSIS when we have RSVP ?
RSVP specifies two service types and we hard-coded only one service type 
in the basic-specification of NSIS ?????????
The bearer service definition was separately specified in a separate 
working group.
In NSIS we integrate everything in one spec.

I get more and more confused....

>     However, we may just need one QSPEC parameter, say Traffic (Tocken
>     Bucket and Bandwidth)
>     Actually this was also the conclusion that Xiaoming deduced after
>     studying a couple of examples.
>      
>     Furthermore, we could however provide the ability to QoS models to
>     specify which

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 17 Oct 2006 10:54:53 -0400

John:

You also need to understand that there are apples and oranges when we
compare different QOS models.

If you do not dig-in one layer down, you will miss the basic point. Let
me explain as follows:

1.       If you think at the first layer of statement like "QOS Model,"
you will find that all are the same: DiffServ, RSVP, IntServ, Y.1541,
and DSTE. This is providing the illusion as it they are the same.

2.       If you think that what has been the basis for QOS models, you
will get different answers: Type I - Based on characteristics of
Services with non-defined specific values (DiffServ, RSVP, and IntServ)
and Type II: QOS models depend on "specific" arbitrary values (Y.1541,
and DSTE).

3.       Like NSIS QOS signaling protocol that is general enough not to
be tied based on specific values that are the usual characteristics for
a set of given implementations, only Type I (DiffServ, RSVP, and
IntServ) QOS models will be compatible. All Type I (DiffServ, RSVP, and
IntServ) QOS models are compatible among themselves. That is, DiffServ,
RSVP, and IntServ QOS models can interwork with proper mapping among
themselves as they have been defined with some specific application
service features/parameters (NOT based on some arbitrary values).

4.       Unlike NSIS QOS signaling protocol that is generalized to be
used under any specific implementations, Type II (Y.1541, and DSTE) QOS
Models are incompatible in all respects. That is, they are incompatible
for interworking between Y.1541 and DSTE as well as they are
incompatible between Type I and Type II QOS model.

5.       NSIS QOS signaling protocol is facing problems when QSPEC
templates contain all the QOS parameters mixing with Type I and Type II
QOS parameters. Here are the problems of mixing between "apples" and
"oranges" as explained above.

6.       Georgios, Lasse and others have come to the same conclusion of
incompatibility of interworking because of the above (e.g., one deals
with "bandwidth" while other deals with 50-ms. How do you make
interworking between these two, etc. etc.?).

So, it is NOT too complicated. It is the problem of generalizing two
incompatible QOS models as if mixing between water and oil.

AD will be better advised not to generalize ITU-T's Y.1541 QOS model
with IETF's DiffServ/RSVP. In this way, problems can be isolated, and
QOS issues will take its own turn.

Let Y.1541 QOS model stand on its own foot writing a stand-alone showing
how to use NSIS QOS signaling protocol for this specific implementation.
We have seen that any mandate that allows the Y.1541/DSTE QOS model to
be generalized for interworking with DIffServ/RSVP while using NSIS QOS
signaling protocol is NOT going to happen because of the incompatibility
problems.

Recently, some technical twist has been seen to quantify so-called QOS
classes of Y.1541 like high, medium, and low, as if, Y1541 QOS models,
are also on the same basis like that of Type I QOS model based on
non-specific "values."  This technical twist will NOT help as it is
distorting the technical fact more.

Best regards,

Radhika

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, October 17, 2006 9:45 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

thanks,

John

	yes. 

	

	
	regards Lasse

	Hi Lars

	Best Regards,
	Georgios

	On 10/16/2006, "Lars Westberg" <[email-masked]>
<mailto:[email-masked]>  wrote:

		Hi,
		The template seems not to be a template because the
mandatory part  is
		more or less the same as Intserv.
		The main idea with QoS-template was to make an modular
solution that
		could allow flexibillity for different Qos-models

		I suggest that we move the major part of the parameters
to a separate
		"Int.serv. over NSIS" specification.
		Int.serv. can be seen as a common bearer service.
		 
		regards Lasse

			Lars,

			John can call a different consensus if he sees
one (I've asked him a
			couple of times to do that).  What I saw was
			 
			1. Many posts supported the QSPEC-1 concept,
only one (or maybe two) I
			saw opposed.  The opposing view was repeated
*many* times (and is still
			being repeated) but it only counts as one
opinion.
			2. Many posts supported retaining the 4 QSPEC-1
parameters, only one I
			saw opposed.  The opposing view was repeated
many times.
			3. There was only one opinion expressed to be
able to ignore QSPEC-1
			parameters.  That one opinion has been repeated
many times but it only
			counts as one opinion.
			 
			John asked a while ago for new opinions on these
issues, that would be
			good if there are any *new* opinions.  We don't
need to hear opinions
			repeated that we've seen so many times.
			 
			I invite John once again to make a consensus
call so we can move on
			here.  I think it is time to make progress and
stop repeating ourselves,
			we're not generating any new light in this
rather endless discussion.
			 
			Thanks,
			Jerry

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 17 Oct 2006 10:58:14 -0400

Georgios:

I fear that it will also not solve the basic problem of incompatibility.
Please see my email. It is just too much to solve as these are still
subjective interpretations and too complex to implement for clear
interworking.

Best regards,

Radhika

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Georgios Karagiannis
Sent: Tuesday, October 17, 2006 10:51 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Hi John

However, an end-to-end QoS model may mandate the use of a QSPEC
parameter. 

(strictly or remap) this parameter. The remapping is then specified in
the end -to-end QOSM draft.

Another local QoS model that needs to interoperate with the end-to-end
QoS model it will either 

have to strictly interpret the parameter specified by the end -to- end
QoS model, or to remap it. 

NON-QOSM Hop flag. 

Best Regards,

Georgios

	 

	Georgios,

	About having the QoS Models specifying manditory parameters -
could you explain how we would get interoperability between two
different QoS models that have different sets of manditory parameters?

	I think we need to have a baseline QSPEC with manditory
parameters to ensure interoperability - we should have the lowest common
denominator between the QoS models to ensure some way of being able to
signal across multiple QoS model deployments.

	John

		From: ext Georgios Karagiannis
[mailto:[email-masked]] 
		Sent: 17 October, 2006 01:40
		To: 'Lars Westberg'
		Cc: [email-masked]; [email-masked]
		Subject: RE: [NSIS] I-D
ACTION:draft-ietf-nsis-qspec-12.txt

		Hi Lars

		However, we may just need one QSPEC parameter, say
Traffic (Tocken Bucket and Bandwidth) 

		that can be mandatory. In this way we will provide the
required interoperability between the 

		QoS models.

		Actually this was also the conclusion that Xiaoming
deduced after studying a couple of examples.

		Furthermore, we could however provide the ability to QoS
models to specify which 

		What do you think?

		Best regards,

		Georgios

			

			From: Lars Westberg

			yes. 

			

			
			regards Lasse

			Hi Lars

			Best Regards,
			Georgios

				Hi,

				 
				regards Lasse

				Lars,

				 

				 
				Thanks,
				Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 17:10:55 +0200

Hi Radhika
 
I think that Jukka just suggested a very good solution to this problem!
 
Best Regards,
Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 17 oktober 2006 16:58
To: Georgios Karagiannis; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Georgios:

Best regards,

Radhika

  _____  

Hi John

NON-QOSM Hop flag. 

Best Regards,

Georgios

 

  _____  

Georgios,

John

  _____  

Hi Lars

QoS models.

What do you think?

Best regards,

Georgios

  _____  

yes. 

regards Lasse

Hi Lars

Best Regards,
Georgios

Hi,

 
regards Lasse

Lars,

 

 
Thanks,
Jerry

---

From: <[email-masked]>
Date: Tue, 17 Oct 2006 16:42:00 -0400

Radhika

I have not been in the middle of this much, but I do want to make a
point to you that may be helpful in deflecting your "anti Y.1541" theme
in NSIS.

Your big complaint seems to be about trying to satisfy the *numerical*
objectives of Y.1541. As I see it, the point for NSIS has never been to
focus on those numerical objectives, but rather that the global
community supports Y.1541 classes as a way to describe (and signal!!!)
e2e IP QoS.

The idea is to enable an implementation capable of addressing the
*parameters* in Y.1541 (which come from Y.1540) and the fact that Y.1541
classes involve a specific combination of parameters-whatever their
numerical values. Thus NSIS should have a way of addressing the global
agreement to describe IP QoS in terms of Y.1541 classes (and thus the
combination of parameters) whether in practice any of the numerical
values of a given class are satisfied, or not.

In other words, whether or not a specific class is numerically satisfied
is not an issue for NSIS, but rather NSIS methods should allow one to
address the need to signal any Y.1541 classes requested.

Regards

Chuck Dvorak

AT&T Labs

---

From: Lars Westberg <[email-masked]>
Date: Wed, 18 Oct 2006 08:05:47 +0200

let's try to breifly discuss the interoperabillity problem.
history:
 From the history we have seen a lot of different QoS-models. Most of 
them has no commercial value today and the typical problem is that they 
have over-engineered the solution. The best outcome of the engineering 
has been weel educated PHD-students that have made a lof of interesting 
thesis.

In general, the interoperabillity is very simple:
Overprovisioning, in the same way Internet is provisioned today. 
Whatever QoS-requirement you have, enough spare capacity solves the 
problem. The only question is related to the requirement for utilization.
In the backbones with low-cost per bit, Overprovisioning of the 
backbones seems today be the most commercially effective way to solve it. 
However, static provisioning or PCN is yet another way to solve the 
bandwidth managent in the backbone if a more bandwidth efficient 
solution is required.

Therefore, the main need for signalled Qos is mainly in the access, not 
in the backbone. If someone need to signal QoS in the access one can 
easily solve it by peak-allocation. Not bandwidth efficient but it 
solves the interoperabillity. The same discussion as for ATM. A CBR can 
encapsulate a VBR-RT.

Inter-operabillity solved by:
1) Overprovisioning in the core such as all QoS-requirments are solved.
2) Interoperabillity for different QoS-models =>Peak-allocation of 
bandwidth.

The major problem is that Qspec-1 doesn't make the solution future proof 
considering different access types and scenarios.

Just as an example the current specification does not cover the 
QoS-requirements for UDP-lite. UDP-lite was develop for partial checksum 
coverage for wireless access. The two part of the payload requires 
different QoS-treatments: one QoS that covered by the checksum and one 
for the part that can accept bit-errors.

My suggestion is that the Template is changed so it's only contain 
optional parameters description.

regards Lasse

Georgios Karagiannis wrote:

>     I fear that it will also not solve the basic problem of
>     incompatibility. Please see my email. It is just too much to solve
>     as these are still subjective interpretations and too complex to
>     implement for clear interworking.
>
>      
>
>     Best regards,
>
>     Radhika
>
>      
>
>     From: [email-masked] [mailto:[email-masked]] On
>     Behalf Of Georgios Karagiannis
>     Any QNE that suopports this end-to-end QoS model then it will have
>     to interpret
>
>     (strictly or remap) this parameter. The remapping is then
>     specified in the end -to-end QOSM draft.
>
>      
>
>     Another local QoS model that needs to interoperate with the
>     end-to-end QoS model it will either
>
>     have to strictly interpret the parameter specified by the end -to-
>     end QoS model, or to remap it. 
>
>     However, if a QNE does not support the end-to-end QoS model then
>     it will just set the
>
>     NON-QOSM Hop flag.
>
>         could you explain how we would get interoperability between
>         two different QoS models that have different sets of manditory
>         parameters?
>
>          
>
>         parameters to ensure interoperability - we should have the
>         lowest common denominator between the QoS models to ensure
>         some way of being able to signal across multiple QoS model
>         deployments.
>
>          
>
>         John
>
>              
>
>                 Standardization organization that like to discuss
>                 "bearer services". Just as an example :
>                 If we specify the those parameters, How can we use
>                 NSIS for SLAs specified by MEF????
>
>                 In the draft I also see  that we the draft specify a
>                 new bearer service. It is not compliant to old
>                 Int.serv architecture.  This is a completely new one
>                 discussion that we should not specify any
>                 "bearer-service" because NSIS should be a modular
>                 architecture with  more flexibillity than RSVP. 
>                 Therefore, I am surprised that we are doing the same
>                 mistake as in RSVP: Integrating a bearer service
>                 If we go this track, the QoS-part of NSIS has much
>                 less use. RSVP is in this case significantly better in
>                 terms of performance and have the same functionality
>                 than NSIS.
>                 If have to choose I would select RSVP rather than a
>                 much more complex  three layer protocol stack.
>
>                 regards Lasse
>
>On 10/16/2006, "Lars Westberg" <[email-masked]> <mailto:[email-masked]> wrote:
>
> 
>
>  
>
>>Hi,
>>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 18 Oct 2006 10:07:30 +0200

Lasse,
 
I fully support your view. *Peak Bandwidth* is sufficient as a mandatory
parameter. I too expect QoS by resource reservations to be limited to
the access. As soon as multiplexing effects can be exploited, PCN, RMD
or the like seem to be more effective than per flow reservations. So if
admission control based on resource reservations is applied, peak
bandwidth is the parameter you look for.
 
The QOSM should carry information on the DSCP(s) to be used.
 
Regards,
 
Rudiger

 .... Inter-operabillity solved by: 
1) Overprovisioning in the core such as all QoS-requirments are solved.
2) Interoperabillity for different QoS-models =>Peak-allocation of
bandwidth.

 ...... 

regards Lasse

Hi Radhika

Best Regards,
Georgios

  _____  

From: [email-masked] [ mailto:[email-masked]] 

Georgios:

Best regards,

Radhika

  _____  

From: [email-masked] [ mailto:[email-masked]] On Behalf Of
Georgios Karagiannis

Hi John

NON-QOSM Hop flag. 

Best Regards,

Georgios

  _____  

From: [email-masked] [ mailto:[email-masked]] 

Georgios,

John

  _____  

From: ext Georgios Karagiannis [ mailto:[email-masked]] 
Sent: 17 October, 2006 01:40
To: 'Lars Westberg'
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Hi Lars

QoS models.

What do you think?

Best regards,

Georgios

  _____  

From: Lars Westberg [ mailto:[email-masked]] 
Sent: dinsdag 17 oktober 2006 8:46
To: Georgios Karagiannis
Cc: [email-masked]; [email-masked]
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

yes. 

regards Lasse

Hi Lars

Best Regards,
Georgios

Hi,

 
regards Lasse

Lars,

 

 
Thanks,
Jerry

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Wed, 18 Oct 2006 10:08:57 +0200

sure, that's ok.

From: Geib, Ruediger [mailto:[email-masked]] 
Sent: den 18 oktober 2006 10:08
To: Lars Westberg (KI/EAB)
Cc: [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Lasse,
 
I fully support your view. *Peak Bandwidth* is sufficient as a mandatory parameter. I too expect QoS by resource reservations to be limited to the access. As soon as multiplexing effects can be exploited, PCN, RMD or the like seem to be more effective than per flow reservations. So if admission control based on resource reservations is applied, peak bandwidth is the parameter you look for.

Regards,
 
Rüdiger

	 .... Inter-operabillity solved by: 
	1) Overprovisioning in the core such as all QoS-requirments are solved.
	2) Interoperabillity for different QoS-models =>Peak-allocation of bandwidth.
	
	 ...... 
	My suggestion is that the Template is changed so it's only contain optional parameters description.
	
	regards Lasse

	

		Hi Radhika

		Best Regards,
		Georgios

			To: Georgios Karagiannis; [email-masked]; [email-masked]

			Georgios:

			I fear that it will also not solve the basic problem of incompatibility. Please see my email. It is just too much to solve as these are still subjective interpretations and too complex to implement for clear interworking.

			Best regards,

			Radhika

			From: [email-masked] [mailto:[email-masked]] On Behalf Of Georgios Karagiannis

			Hi John

			Any QNE that suopports this end-to-end QoS model then it will have to interpret 

			(strictly or remap) this parameter. The remapping is then specified in the end -to-end QOSM draft.

			Another local QoS model that needs to interoperate with the end-to-end QoS model it will either 

			have to strictly interpret the parameter specified by the end -to- end QoS model, or to remap it. 

			However, if a QNE does not support the end-to-end QoS model then it will just set the 

			NON-QOSM Hop flag. 

			Best Regards,

			Georgios

				

				Georgios,

				About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS models that have different sets of manditory parameters?

				I think we need to have a baseline QSPEC with manditory parameters to ensure interoperability - we should have the lowest common denominator between the QoS models to ensure some way of being able to signal across multiple QoS model deployments.

				John

					Hi Lars

					However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth) 

					that can be mandatory. In this way we will provide the required interoperability between the 

					QoS models.

					Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples.

					Furthermore, we could however provide the ability to QoS models to specify which 

					What do you think?

					Best regards,

					Georgios

					

					yes. 
					the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example :
					If we specify the those parameters, How can we use NSIS for SLAs specified by MEF????

					In the draft I also see  that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture.  This is a completely new one with new parameters like priority.
					
					I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.
					
					I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture.
					
					If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS.
					If have to choose I would select RSVP rather than a much more complex  three layer protocol stack.
					
					regards Lasse

					Hi Lars

					Best Regards,
					Georgios

					Hi,

					 
					regards Lasse

					Lars,

					 

					 
					Thanks,
					Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 18 Oct 2006 10:40:21 +0200

Hi all
 
I also support the point of view of Lars that peak bandwdith is the only
parameter that can be used to provide interoperability.
 
Best regards,
Georgios

  _____  

From: Geib, Ruediger [mailto:[email-masked]] 
Sent: woensdag 18 oktober 2006 10:08
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Lasse,
 
I fully support your view. *Peak Bandwidth* is sufficient as a mandatory
parameter. I too expect QoS by resource reservations to be limited to the
access. As soon as multiplexing effects can be exploited, PCN, RMD or the
like seem to be more effective than per flow reservations. So if admission
control based on resource reservations is applied, peak bandwidth is the
parameter you look for.

Regards,
 
Rüdiger

 ...... 
My suggestion is that the Template is changed so it's only contain optional
parameters description.

regards Lasse

Hi Radhika

Best Regards,
Georgios

  _____  

Georgios:

Best regards,

Radhika

  _____  

Hi John

NON-QOSM Hop flag. 

Best Regards,

Georgios

  _____  

Georgios,

John

  _____  

Hi Lars

QoS models.

What do you think?

Best regards,

Georgios

  _____  

yes. 

regards Lasse

Hi Lars

Best Regards,
Georgios

Hi,

 
regards Lasse

Lars,

 

 
Thanks,
Jerry

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 18 Oct 2006 09:43:16 -0400

Chuck:

You will be better advised to reply with all technical points that I
have provided in my all emails including John's.

I have no objections that Y.1541's grand QOS schemes should be addressed
with all those so-called arbitrary value-based QOS classes all by
itself, and we all will help it to make it happen as a stand-alone
scheme. The whole world may accept what they want to use as they like in
their specific values. It is nothing to do with DiffServ or RSVP. 

When it comes to interworking of Y.1541 with DiffServ, RSVP, and
IntServ, it is a mixture of between water and oil. It is a simple common
sense because of the fundamental properties: Implementation-specific
value-based QOS parameters versus Non-Implementation-specific
non-value-based QOS parameters.

No amount of words or twist in technical statements like high, low, or
medium will be able to make it work for Interworking.

You will be better advised to call-off the QSPEC draft for Interworking
between Y.1541, DiffServ, and DSTE parameters in the same QSPEC draft.
Let Y1541 QSPEC draft be a stand-alone draft. No one will object to
stand Y.1541 on its own feet using NSIS QOS signaling protocol.

Unless you address the root cause of all problems, nothing good will
come out of it other than the messy technical debates that we are
observing in this mailing list what I predicted almost 2 years ago.

It is a question of Interworking in standards.

Best regards,

Radhika

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 17, 2006 4:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Radhika

Regards

Chuck Dvorak

AT&T Labs

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 18 Oct 2006 10:36:54 -0400

Lars:

You are right. That is why, the QOS model like DiffServ comes into
picture.

There is another aspect of these QOS models so far the standardization
is concerned. That is called interwoking between the different QOS
modeling standards. For example, you have mentioned as follows:

All the trends of QOS models have been basically like the above.

Recently, we also see some fertile brains have created some so-called
"Implementation-specific QOS schemes" that are based on "values" of all
QOS parameters. The fundamental problems are that they also called these
as QOS models (instead of saying that these are some QOS
"implementation" schemes, NOT QOS models). They have even convinced few
folks here and there of different standard organizations that they need
"interworking" between different QOS models.

Here the fundamental problems come. Who is kidding whom trying to mixing
between water and oil? 

Best regards,

Radhika

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2006 2:06 AM
To: [email-masked]
Cc: Georgios Karagiannis; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

In general, the interoperabillity is very simple: 
Overprovisioning, in the same way Internet is provisioned today.
Whatever QoS-requirement you have, enough spare capacity solves the
problem. The only question is related to the requirement for
utilization.
In the backbones with low-cost per bit, Overprovisioning of the
backbones seems today be the most commercially effective way to solve
it.  
However, static provisioning or PCN is yet another way to solve the
bandwidth managent in the backbone if a more bandwidth efficient
solution is required. 

regards Lasse

Hi Radhika

Best Regards,

Georgios

	

	Georgios:

	I fear that it will also not solve the basic problem of
incompatibility. Please see my email. It is just too much to solve as
these are still subjective interpretations and too complex to implement
for clear interworking.

	Best regards,

	Radhika

	Hi John

	First of all: the QSPEC template does not specify  mandatory
parameters.

	Any QNE that suopports this end-to-end QoS model then it will
have to interpret 

	have to strictly interpret the parameter specified by the end
-to- end QoS model, or to remap it. 

	NON-QOSM Hop flag. 

	Best Regards,

	Georgios

		 

		From: [email-masked]
[mailto:[email-masked]] 
		Sent: dinsdag 17 oktober 2006 16:21
		To: [email-masked]; [email-masked]
		Cc: [email-masked]; [email-masked]
		Subject: RE: [NSIS] I-D
ACTION:draft-ietf-nsis-qspec-12.txt

		Georgios,

		About having the QoS Models specifying manditory
parameters - could you explain how we would get interoperability between
two different QoS models that have different sets of manditory
parameters?

		John

			Hi Lars

			However, we may just need one QSPEC parameter,
say Traffic (Tocken Bucket and Bandwidth) 

			that can be mandatory. In this way we will
provide the required interoperability between the 

			QoS models.

			Actually this was also the conclusion that
Xiaoming deduced after studying a couple of examples.

			Furthermore, we could however provide the
ability to QoS models to specify which 

			What do you think?

			Best regards,

			Georgios

				

				From: Lars Westberg

				yes. 
				the main problem is that IETF is not the
only Standardization organization that like to discuss "bearer
services". Just as an example :
				If we specify the those parameters, How
can we use NSIS for SLAs specified by MEF????
				
				How can we use it for 3GPP-Qos
definitiions ?

				In the draft I also see  that we the
draft specify a new bearer service. It is not compliant to old Int.serv
architecture.  This is a completely new one with new parameters like
priority.
				
				I can sure that we can have a
never-ending discussion about the "optimal"-set of parameters.
				
				I think we agree in beggining the
working group discussion that we should not specify any "bearer-service"
because NSIS should be a modular architecture with  more flexibillity
than RSVP.  Therefore, I am surprised that we are doing the same mistake
as in RSVP: Integrating a bearer service definition into the
NSIS-architecture.
				
				If we go this track, the QoS-part of
NSIS has much less use. RSVP is in this case significantly better in
terms of performance and have the same functionality than NSIS.
				If have to choose I would select RSVP
rather than a much more complex  three layer protocol stack.
				
				regards Lasse

				

				Hi Lars

				Best Regards,
				Georgios

				Hi,

				 
				regards Lasse

				Lars,

				 

				 
				Thanks,
				Jerry

---

From: Stephane Ouellette <[email-masked]>
Date: Wed, 18 Oct 2006 14:15:35 -0400

Hi all,

    I also support Lars' point of view. Any other combination of Qos 
parameters will lead to incompatibilities with existing or future QoS 
models.

Regards,

Stephane.

Georgios Karagiannis wrote:
>     *From:* Geib, Ruediger [mailto:[email-masked]]
>     *Sent:* woensdag 18 oktober 2006 10:08
>     *To:* [email-masked]
>     *Cc:* [email-masked]
>     *Subject:* RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt
> 
>     Lasse,
>      
>     I fully support your view. *Peak Bandwidth* is sufficient as a
>     mandatory parameter. I too expect QoS by resource reservations to be
>     limited to the access. As soon as multiplexing effects can be
>     exploited, PCN, RMD or the like seem to be more effective than per
>     flow reservations. So if admission control based on resource
>     reservations is applied, peak bandwidth is the parameter you look for.
>      
>>             *From:* [email-masked]
>>             [mailto:[email-masked]]
>>             *Sent:* dinsdag 17 oktober 2006 16:58
>>             *To:* Georgios Karagiannis; [email-masked];
>>             *Cc:* [email-masked]; [email-masked]
>>             *Subject:* RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt
>>
>>             Georgios:
>>
>>             incompatibility. Please see my email. It is just too much
>>             to solve as these are still subjective interpretations and
>>             too complex to implement for clear interworking.
>>
>>             Best regards,
>>
>>             Radhika
>>
>>             *From:* [email-masked]
>>             [mailto:[email-masked]] *On Behalf Of *Georgios
>>             Karagiannis
>>             *Sent:* Tuesday, October 17, 2006 10:51 AM
>>             *To:* [email-masked]; [email-masked]
>>             *Cc:* [email-masked]; [email-masked]
>>             *Subject:* RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt
>>
>>             Hi John
>>
>>                 *From:* [email-masked]
>>                 *Sent:* dinsdag 17 oktober 2006 16:21
>>                 *To:* [email-masked]; [email-masked]
>>                 *Cc:* [email-masked]; [email-masked]
>>                 *Subject:* RE: [NSIS] I-D
>>                 parameters - could you explain how we would get
>>                 interoperability between two different QoS models that
>>                 have different sets of manditory parameters?
>>
>>                 I think we need to have a baseline QSPEC with
>>                 manditory parameters to ensure interoperability - we
>>                 should have the lowest common denominator between the
>>                 QoS models to ensure some way of being able to signal
>>                     *From:* ext Georgios Karagiannis
>>                     *Sent:* 17 October, 2006 01:40
>>                     *To:* 'Lars Westberg'
>>                     *Cc:* [email-masked]; [email-masked]
>>                     *Subject:* RE: [NSIS] I-D
>>                     that can be mandatory. In this way we will provide
>>                     the required interoperability between the
>>
>>                     QoS models.
>>
>>                         *From:* Lars Westberg
>>                         *Sent:* dinsdag 17 oktober 2006 8:46
>>                         *To:* Georgios Karagiannis
>>                         *Cc:* [email-masked]; [email-masked]
>>                         *Subject:* Re: [NSIS] I-D
>>                         Standardization organization that like to
>>                         discuss "bearer services". Just as an example :
>>                         specify a new bearer service. It is not
>>                         compliant to old Int.serv architecture.  This
>>                         I think we agree in beggining the working
>>                         group discussion that we should not specify
>>                         any "bearer-service" because NSIS should be a
>>                         modular architecture with  more flexibillity
>>                         than RSVP.  Therefore, I am surprised that we
>>                         are doing the same mistake as in RSVP:
>>                         much less use. RSVP is in this case
>>                         significantly better in terms of performance

---

From: <[email-masked]>
Date: Wed, 18 Oct 2006 20:15:31 -0400

Radhika

Water and oil aside, the Y.1541 QoS classes are not
"implementation-specific" as you say. They may use DiffServ, they may
use RSVP, they may use something else. How is that
implementation-specific?

For me, this misunderstanding by you is the root cause of your
criticism. (I understand your argument-I just do not agree with it,
because it is inaccurate.)

The Y.1541 classes are QoS classes that many experts around the world
agreed capture, in a reasonably small number, distinct combinations of
IP performance parameters capable of supporting virtually all user
applications with the requisite QoS. On an e2e basis, a user may for
example indicate "I am using IPTV and want to request Y.1541 Class 5,
which would satisfy my QoS needs." Networks in the path may implement
different QoS schemes (per-hop, per-domain, whatever), but a good NSIS
method will still allow the e2e QoS classes (of Y.1541) to be addressed.

But there is no effective way to signal this e2e today, and that is what
many of us wanted NSIS to do-signal this e2e need, with enough hooks to
be useful. 

If all that is done in NSIS is to make incremental improvements to RSVP,
or to focus primarily on signaling peak bandwidth needs, then IMO the
end result will not be nearly as useful as many of us had hoped.

Chuck Dvorak

AT&T Labs Research

From: Roy, Radhika R. [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2006 10:37 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Georgios Karagiannis; [email-masked];
[email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Lars:

Best regards,

Radhika

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 01:05:59 -0400

One more time from left-field (I know... I've lost this one before  
and should keep my mouth shut).

Much of this confusion is because I believe the qspec draft and the  
current notion of "QoS models" has a poor architectural partitioning  
and hence falls into these kinds of discussions of what is over and  
under specification, what it means for a parameter to be mandatory, etc.

A long time ago I proposed a different architectural partitioning  
(and moving some things like priority outside the qspec entirely  
since it was a general admission control parameter and not a QoS  
parameter). I won't resurrect the whole thing here but remind people  
if they want to go back a couple of years in the archives they;ll  
find the outline of the proposal and the ensuing discussion. I shut  
up because the WG consensus was against my proposal and I'm not in  
the habit of continuing to make a pain of myself when I lose an  
argument.

However, it does strike me that this long thread and the last-minute  
discussions on the qspec draft do have a flavor of the issues I was  
raising way back when. Just to remind folks, I proposed, more or less:

a) a set of parameters, all mandatory, that describe the traffic  
source in a mathematically complete way.
b) a set of parameters, all optional, which give additional hints  
about characteristics of the source traffic which may allow network  
elements to optimize their treatment (compressibility hints, pre- 
encryption hints)
c) a set of parameters, mostly optional, that describe the QoS  
constraints the source wishes applied to the treatment of this  
traffic (loss rate, jitter, sensitivity to out of order delivery, etc.)
d) a set of handling directives, all optional, which specify the  
source's preferences for for traffic handling (e.g. excess treatment)

I think there are a number of ways to close down this discussion ,  
through which I notice there have been only a few people complaining:

a) tell them to shut up, that the WG consensus stands, and see what  
happens during last call.
b) rethink the spec along the lines I outline above and ask those  
folks if that would address their concerns
c) ask for a formal outside review, either by raising these issues  
explicitly in the last call and requesting comments, or punting to  
the IESG to solicit such advice.

I promise not to rock the boat if you choose (a).

Dave  Oran.

On Oct 17, 2006, at 8:32 AM, Lars Westberg wrote:

>
> The specification of Qspec1 is mandatory and therefore as I can see  
> can not be avoided and
> The reason for dividing NSIS in three layers was that Int.serv.   
> was too tightly built-into RSVP.
> If one just read the specification, and compare it with Int.serv.  
> oe can conclude the following:
> ...more layers with more functionality in each layer stacked on  
> each other. I do not know what to do.....
>
> regards Lasse
>
>
>
> Kappler, Cornelia wrote:
>> Hi Lasse,
>>
>> The job of the QSPEC draft is to define a set of parameters that  
>> QOSM specs can choose from to define this treatment. (Would you  
>> agree this is a reasonable approach?)
>>
>> Could you more concretely point out where in the QSPEC a specific  
>> flow treatment is defined - beyond the (necessary) description of   
>> how a particular parameter should be dealt with?
>>> we should not specify any "bearer-service" because NSIS should be  
>>> a modular architecture with  more flexibillity than RSVP.   
>>> Therefore, I am surprised that we are doing the same mistake as  
>>> in RSVP: Integrating a bearer service definition into the NSIS- 
>>> architecture.
>>>
>>>> Hi Lars Do you mean that the QSPEC template must not contain any  
>>>> mandatory (QSPEC-1) parameters? Best Regards, Georgios On  
>>>> 10/16/2006, "Lars Westberg" <[email-masked]> wrote:
>>>>> Hi, The template seems not to be a template because the  
>>>>> mandatory part is more or less the same as Intserv. The main  
>>>>> idea with QoS-template was to make an modular solution that  
>>>>> could allow flexibillity for different Qos-models Therefore, I  
>>>>> do not understand the scope of the specification. I suggest  
>>>>> that we move the major part of the parameters to a separate  
>>>>> "Int.serv. over NSIS" specification. Int.serv. can be seen as a  
>>>>> common bearer service. regards Lasse Ash, Gerald R (Jerry),  
>>>>> ALABS wrote:
>>>>>> Lars,
>>>>>>> issues, while there is a huge discussion on the nsis mailing  
>>>>>>> list regarding the QSPEC-1 parameters.
>>>>>> John can call a different consensus if he sees one (I've asked  
>>>>>> him a couple of times to do that). What I saw was 1. Many  
>>>>>> posts supported the QSPEC-1 concept, only one (or maybe two) I  
>>>>>> saw opposed. The opposing view was repeated *many* times (and  
>>>>>> is still being repeated) but it only counts as one opinion. 2.  
>>>>>> Many posts supported retaining the 4 QSPEC-1 parameters, only  
>>>>>> one I saw opposed. The opposing view was repeated many times.  
>>>>>> times but it only counts as one opinion. John asked a while  
>>>>>> ago for new opinions on these issues, that would be good if  
>>>>>> there are any *new* opinions. We don't need to hear opinions  
>>>>>> repeated that we've seen so many times. I invite John once  
>>>>>> again to make a consensus call so we can move on here. I think  
>>>>>> it is time to make progress and stop repeating ourselves,  
>>>>>> we're not generating any new light in this rather endless  
>>>>>> discussion. Thanks, Jerry

---

From: Lars Westberg <[email-masked]>
Date: Thu, 19 Oct 2006 09:14:45 +0200

The basic problem is that NSIS only mandating only one service type in 
the basic set of protocol specifications. In RSVP one can change 
parameters without make a new revision of the basic protocol specs.

regards Lasse
[email-masked] wrote:

> criticism. (I understand your argument--I just do not agree with it, 
> But there is no effective way to signal this e2e today, and that is 
> what many of us wanted NSIS to do--signal this e2e need, with enough 
> hooks to be useful.
>
>  
>
> If all that is done in NSIS is to make incremental improvements to 
> RSVP, or to focus primarily on signaling peak bandwidth needs, then 
> IMO the end result will not be nearly as useful as many of us had hoped.
>
>  
>
I am very interested to get more information.  Send me a mail directly.

> "Implementation-specific QOS schemes" that are based on "values" of 
> all QOS parameters. The fundamental problems are that they also called 
> these as QOS models (instead of saying that these are some QOS 
> "implementation" schemes, NOT QOS models). They have even convinced 
> few folks here and there of different standard organizations that they 
> need "interworking" between different QOS models.
>
>  
>
> Here the fundamental problems come. Who is kidding whom trying to 
> mixing between water and oil?
>
>  
>
> Best regards,
>
> Radhika
>

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 19 Oct 2006 09:33:55 +0200

Dave,

I'm still listening, anyway :-)

My understanding of the situation is that the a/b/c/d classification
you describe below is not so far from the intentions of the current 
Qspec. One open question is about which parameters fall into which 
category; other people are saying "give up and make everything 
optional". Please see further below.

> From: David R Oran [mailto:[email-masked]] 
> Sent: 19 October 2006 07:06
> To: Lars Westberg
> Cc: [email-masked]; Georgios Karagiannis; [email-masked]; 
> Kappler, Cornelia

The current spec includes bandwidth and a token bucket in this 
category. Most people seem to agree that it is reasonable to 
demand that everyone understand the bandwidth parameter; personally
I don't know how to interpret a bandwidth except over a timescale
which is then basically a token bucket anyway.

> elements to optimize their treatment (compressibility hints, pre- 

I don't think we have any of these yet, but since they are all optional
they are easy to add.

> the IESG to solicit such advice.

Well, Jukka has suggested to ask the IAB, on which you sit...

Robert H.

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 03:53:49 -0400

On Oct 19, 2006, at 3:33 AM, Robert Hancock wrote:

> Qspec.
No, it isn't too far, because we all know that the various things/ 
parameters you want to talk about have certain semantics and we (at  
least so far) don't have a deep disagreement about the semantics. The  
disagreement is about the systematics/taxonomy and the relationship  
between things which describe the source traffic, the things which  
describe the constraints the source believes have to be met to  
believe that its traffic has been admitted when the NSIS signaling  
says it's been admitted., and the things which the source would like  
to tell the network about traffic handling when things do not "go  
according to plan", or if there are extra resources or good news of  
some sort.

> One open question is about which parameters fall into which
I don't see any benefit to making parameters which are necessary to  
mathematically describe the source traffic optional.

> which is then basically a token bucket anyway.
Right. I fail to understand how "bandwidth" differs from "average  
rate" in a token bucket if your QoS treatment is only capable of  
meeting the bandwidth demands over an arbitrarily long time scale. in  
other words, it makes things complicated and very confusing to have  
both. I think there's a big difference between a source that says it  
needs "1mbps" and generates 100mbps in a burst and then shuts up for  
99 seconds, expecting the network to absorb and shape that burst, and  
a source that actually states the TSPEC to describe its traffic  
generation process. My argument is that this is totally independent  
of this notion of "QOS models" which has been adopted by the NSIS  
community. QOS models are all about defining equivalence classes of  
constraints a given set of machinery deployed in a portion of the  
internet are capable of meeting when the traffic arrives. I am also  
of the view that defining QOS models has limited or no utility, but  
that is a separate discussion and a battle I have no desire to fight  
in parallel.

> I don't think we have any of these yet, but since they are all  
The key is that they are *traffic source descriptions* and not  
related to any given "QoS model". I keep hammering on this  
systematics/taxonomy issue because I think have the taxonomy along  
the mandatory/optional axis is misleading and in many ways  
fundamentally un-useful, except to save transmitting stuff in messages.

> Well, Jukka has suggested to ask the IAB, on which you sit...
And I am mindful that I take care to not to exploit my IAB role to  
attempt to derail a WG consensus. I'm saying my views as an  
individual and will continue to do so (if you don't ask me to shut up).

---

From: Lars Westberg <[email-masked]>
Date: Thu, 19 Oct 2006 10:12:07 +0200

if you should call for consensus, you have to consider other alternative 
as well, not just one person opinion.

Jukkas proposal should be one of them.

-lasse

[email-masked] wrote:

> Dave,
>
> Thanks for your mail, I've been rolling some concepts in my head
> but you have boiled them down to 4 concise points:
>
> >However, it does strike me that this long thread and the
> >last-minute discussions on the qspec draft do have a flavor of
> >the issues I was raising way back when. Just to remind folks,
> >I proposed, more or less:
> >
> >a) a set of parameters, all mandatory, that describe the
> >traffic source in a mathematically complete way.
> >
> >b) a set of parameters, all optional, which give additional
> >hints about characteristics of the source traffic which may
> >allow network elements to optimize their treatment
> >(compressibility hints, pre- encryption hints)
> >
> >d) a set of handling directives, all optional, which specify
> >the source's preferences for for traffic handling (e.g. excess
> >treatment)
>
> So, at this point, I cannot think of a better set of concepts
> to call concensus on.  I'm going to issue a concensus call
> to finalize this.  I see your points as the basic issue to resolve.
>
> thanks,
> John
>

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 11:36:12 +0300

I think that Jukka's suggestion basically falls under Dave's choice D.
 
John

	From: ext Lars Westberg [mailto:[email-masked]] 
	Sent: 19 October, 2006 11:12
	To: Loughney John (Nokia-NRC/Helsinki)
	Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: Re: AW: AW: [NSIS] I-D
ACTION:draft-ietf-nsis-qspec-12.txt

	if you should call for consensus, you have to consider other
alternative as well, not just one person opinion.

	-lasse

		Dave,
		
		Thanks for your mail, I've been rolling some concepts in
my head
		
		>the source's preferences for for traffic handling (e.g.
excess
		
		So, at this point, I cannot think of a better set of
concepts
		to call concensus on.  I'm going to issue a concensus
call
		to finalize this.  I see your points as the basic issue
to resolve.
		
		thanks,
		John

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 05:03:20 -0400

> I think that Jukka's suggestion basically falls under Dave's choice D.
Uh I didn't posit those as choices. I posited the group as a single  
choice, and (a)-(d) as a formal taxonometric system for how to  
describe the parameters. The fact that parameters in groups (b)-(d)  
are mostly optional is a separate degree of freedom. If you buy my  
taxonomy it becomes much more obvious (at least to me) what should be  
mandatory and it gives us a handle to identify, and hopefully  
eliminate parameters that have highly overlapping semantics (e.g.  
average rate versus bandwidth).

For example, if the user puts in a certain parameter in group (c)"QoS  
constraints", and the requested value cannot be met by the "QoS  
Model" somewhere along the path, then admission control fails and the  
user is told "no". Conversely, if the user does not care about some  
QoS constraint parameter, or sets it to a loose constraint e.g. 10%  
loss is ok, then many QoS models can meet the traffic description in  
a given TSPEC from group (a).

Another property of this taxonomy is that it makes QoS models much  
less important in the architecture of NSIS, which some people might  
find an advantage, and some not.

Dave Oran.

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 11:07:20 +0300

Dave,

thanks,
John

---

From: Roland Bless <[email-masked]>
Date: Thu, 19 Oct 2006 11:36:12 +0200

Hi John.

> to finalize this.  I see your points as the basic issue to resolve.

Hmm, I guess that you misunderstood Dave's proposal, because
as far as I understood these were not alternatives to choose from,
but a coarse classification of parameter types, so a QSPEC
template would be structured according to a),b),c),d)

Regards,
 Roland

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 05:38:28 -0400

> template would be structured according to a),b),c),d)
Correct. this is what I intended.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 19 Oct 2006 11:39:24 +0200

Hi John
 
I think that Jukka's proposal could cover b), c) and d).
 
Best regards,
Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 19 oktober 2006 10:36
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

John

  _____  

From: ext Lars Westberg [mailto:[email-masked]] 
Sent: 19 October, 2006 11:12
To: Loughney John (Nokia-NRC/Helsinki)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

if you should call for consensus, you have to consider other alternative as
well, not just one person opinion.

-lasse

Dave,

thanks,
John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 19 Oct 2006 12:04:09 +0200

Hi John
 
After studying the a) to d) points of Dave in more detail 
I think that they are different than the proposal of Jukka!
 
Actually point a) falls under the responability of an interworking activity,
while points b) c) and d)
fall under the QSPEC tem[plate activity!
 
Thus I thinkl that the call should first of all cover the proposal of Jukka!
 
If we follow the proposal of Jukka, then we can a) to provide the
interworking 
and follow b), c) and d)
to finalise the QSPEC template, that in my opinion means:
make all mandator optional and we are done with the QWSPEC template draft!
 
best regards,
Georgios

  _____  

 
John

  _____  

-lasse

Dave,

thanks,
John

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 06:53:50 -0400

> I think that they are different than the proposal of Jukka!
That is correct. My point was quite different.

> Actually point a) falls under the responability of an interworking  
> activity, while points b) c) and d)
That is not what I intended. The idea was to separate the issue of  
source traffic description from the questions of exactly what  
constraints on QoS delivery for such a traffic source have to be met  
by the QoS elements on the path in order to admission control to  
succeed.

> Thus I thinkl that the call should first of all cover the proposal  
Jukka's proposal is to define a unstructured data schema for QoS  
parameters so there are no constraints on what can be expressed in an  
NSIS admission control and QoS signaling transaction. I think this  
approach basically institutionalizes non-interoperability, and hence  
I think it is not a good idea.

> make all mandator optional and we are done with the QWSPEC template  
We are certainly done, but what then will we have accomplished?

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 14:26:28 +0300

Dave,

I know that noone bit when you dangled your proposal in front of 
the wg, but ...

>traffic source in a mathematically complete way.

I do see a big value in having this.  This could be what all
QoS models could map to for interoperability reasons.

I think you had said you had such a model in your back pocket, based
upon some other work you had been involved in. Would you be able to 
forward this to the WG?

John

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 14:30:34 +0300

Yes, I got the point ... I'll revise my mail.

John 

>From: ext Roland Bless [mailto:[email-masked]] 
>Sent: 19 October, 2006 12:36
>concepts to call 
>> concensus on.  I'm going to issue a concensus call to 
>finalize this.  
>> I see your points as the basic issue to resolve.
>
>as far as I understood these were not alternatives to choose 
>from, but a coarse classification of parameter types, so a 
>QSPEC template would be structured according to a),b),c),d)
>
>Regards,
> Roland
>
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 19 Oct 2006 13:41:32 +0200

Hi Dave

 Please see in line!

> Sent: donderdag 19 oktober 2006 12:54
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> > After studying the a) to d) points of Dave in more detail I 
> think that 
> > they are different than the proposal of Jukka!
> >
> > activity, while points b) c) and d) fall under the QSPEC tem[plate 
> > activity!
> >
> That is not what I intended. The idea was to separate the 
> issue of source traffic description from the questions of 
> exactly what constraints on QoS delivery for such a traffic 
> source have to be met by the QoS elements on the path in 
> order to admission control to succeed.
> 
> > Thus I thinkl that the call should first of all cover the 
> proposal of 
> > Jukka!
> >
> Jukka's proposal is to define a unstructured data schema for 
> QoS parameters so there are no constraints on what can be 
> expressed in an NSIS admission control and QoS signaling 
> transaction. I think this approach basically 
> institutionalizes non-interoperability, and hence I think it 
> is not a good idea.

Georgios:
I think that what Jukka meant is as follows:
First let the QSPEC template define the encoding of the QSPEC object and its
parameters.
However, the QSPEC template will not define which of these parameters are
mandatory and which not.

Here I however, I could agree with you 
that the QSPEC template could specify the Traaffic descriptor, 
i.e., Bandwidth, as a manadtory parameter.
This is diferent then having 13 mandatory parameters in the QSPEC template.
This will give the opportunity to QoS models to start the deployment phase.

Furthermore, the QOS models can however define which of the
QSPEc pasrameters (assocaited with the QoS model)
can be mandatory and which optional.

The problem that remains to be solved is to find out how to interwork
between the QoS models.
As a starting point the QSPEC template could define one mandatory parameter
and that is Bandwidth.
This will give the opportunity to let QoS models start the deployment phase.

If during the deployment phase we will see that more parameters must be 
made mandatory then we can start an interworking activity to work out the 
interoperability problem.

 
> > interworking and follow b), c) and d) to finalise the QSPEC 
> template, 
> > that in my opinion means:

Georgios: Please see above. Please note that I agree with you regarding 
the need of having a mandatory Traffic description, 
which in my opinion should be Bandwdith. This will allow 
a basis for interoperability between QoS models.

What do you think?

Best regards,
Georgios

> my head but 
> >> you have boiled them down to 4 concise points:
> >>
> last-minute

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 14:43:25 +0300

Hi all,

I've been in transit for a few days, so trying to catch-up on all mails
is somewhat challenging.  Here's a partially baked proposal, considering
the mails on this thread.  My proposal for the WG to consider  is:

1) We take Dave's proposal as a baseline QSPEC:

a) a set of parameters, all mandatory, that describe the traffic source
in a mathematically complete way.
b) a set of parameters, all optional, which give additional hints about
characteristics of the source traffic which may allow network elements
to optimize their treatment (compressibility hints, pre- encryption
hints)
c) a set of parameters, mostly optional, that describe the QoS
constraints the source wishes applied to the treatment of this traffic
(loss rate, jitter, sensitivity to out of order delivery, etc.)
d) a set of handling directives, all optional, which specify the
source's preferences for for traffic handling (e.g. excess treatment)

2) Allow QoS Models to use a secondary QSPEC, that may not be
mathmetically complete.
3) QoS models specify how to map to the baseline QSPEC.
4) Add a MAP/NO MAP byte, which a QoS Model can use if they want their
model mapped (or not) to domains support QoS models.

Would this meet people's needs?  I could see that point 4 might allow
use cases that Lars/Georgios would like.

Robert and Dave seem to agree that point 1) is not too far from the
current QSPEC.

John

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 14:58:40 +0300

I've got to agree with Chuck on this.   How Y.1541 fufills QoS classes
is not an NSIS issue.  I think it is clear how to carry them, but how
the domain deploying Y.1541 verifies things are fufilled is outslide of
NSIS.
 
John

	From: ext [email-masked]
[mailto:[email-masked]] 
	Sent: 19 October, 2006 03:16
	To: [email-masked]; [email-masked]; Loughney
John (Nokia-NRC/Helsinki)
	Cc: [email-masked]; [email-masked]; [email-masked]
	Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

	Radhika

	The Y.1541 classes are QoS classes that many experts around the
world agreed capture, in a reasonably small number, distinct
combinations of IP performance parameters capable of supporting
virtually all user applications with the requisite QoS. On an e2e basis,
a user may for example indicate "I am using IPTV and want to request
Y.1541 Class 5, which would satisfy my QoS needs." Networks in the path
may implement different QoS schemes (per-hop, per-domain, whatever), but
a good NSIS method will still allow the e2e QoS classes (of Y.1541) to
be addressed.

	But there is no effective way to signal this e2e today, and that
is what many of us wanted NSIS to do-signal this e2e need, with enough
hooks to be useful. 

	If all that is done in NSIS is to make incremental improvements
to RSVP, or to focus primarily on signaling peak bandwidth needs, then
IMO the end result will not be nearly as useful as many of us had hoped.

	Chuck Dvorak

	AT&T Labs Research

	Lars:

	You are right. That is why, the QOS model like DiffServ comes
into picture.

	There is another aspect of these QOS models so far the
standardization is concerned. That is called interwoking between the
different QOS modeling standards. For example, you have mentioned as
follows:

	Inter-operabillity solved by: 
	1) Overprovisioning in the core such as all QoS-requirments are
solved.
	2) Interoperabillity for different QoS-models =>Peak-allocation
of bandwidth.

	Recently, we also see some fertile brains have created some
so-called "Implementation-specific QOS schemes" that are based on
"values" of all QOS parameters. The fundamental problems are that they
also called these as QOS models (instead of saying that these are some
QOS "implementation" schemes, NOT QOS models). They have even convinced
few folks here and there of different standard organizations that they
need "interworking" between different QOS models.

	Here the fundamental problems come. Who is kidding whom trying
to mixing between water and oil? 

	Best regards,

	Radhika

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 19 Oct 2006 07:59:55 -0400

Can you please rephrase number 4?  I don't understand it the way it is
currently written.

Thanks

Janet

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 19 Oct 2006 14:06:25 +0200

Hi John
 
>> is not an NSIS issue.  I think it is clear how to carry them, but 
>> how the domain deploying Y.1541 verifies things are fufilled is outslide
of NSIS.
 
What do you mean?
If NSIS specifies that the QOS classes MUST be interpreted, then it means
that they MUST be 
interpreted by all the QNEs, because the QSPEC template is requirig 
that from them, even if they do not need to interpret them!
Thus actually what NSIS requires from the nodes is 
to be Diffserv, MPLS and Y.1541 aware, otherwise they will not be able to 
use NSIS.
Is this what we want with NSIS?
 
Best regards,
Georgios

 

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 19 oktober 2006 13:59
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

I've got to agree with Chuck on this.   How Y.1541 fufills QoS classes is
not an NSIS issue.  I think it is clear how to carry them, but how the
domain deploying Y.1541 verifies things are fufilled is outslide of NSIS.
 
John

  _____  

From: ext [email-masked] [mailto:[email-masked]] 
Sent: 19 October, 2006 03:16
To: [email-masked]; [email-masked]; Loughney John
(Nokia-NRC/Helsinki)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Radhika

Water and oil aside, the Y.1541 QoS classes are not
"implementation-specific" as you say. They may use DiffServ, they may use
RSVP, they may use something else. How is that implementation-specific?

For me, this misunderstanding by you is the root cause of your criticism. (I
understand your argument-I just do not agree with it, because it is
inaccurate.)

The Y.1541 classes are QoS classes that many experts around the world agreed
capture, in a reasonably small number, distinct combinations of IP
performance parameters capable of supporting virtually all user applications
with the requisite QoS. On an e2e basis, a user may for example indicate "I
am using IPTV and want to request Y.1541 Class 5, which would satisfy my QoS
needs." Networks in the path may implement different QoS schemes (per-hop,
per-domain, whatever), but a good NSIS method will still allow the e2e QoS
classes (of Y.1541) to be addressed.

But there is no effective way to signal this e2e today, and that is what
many of us wanted NSIS to do-signal this e2e need, with enough hooks to be
useful. 

If all that is done in NSIS is to make incremental improvements to RSVP, or
to focus primarily on signaling peak bandwidth needs, then IMO the end
result will not be nearly as useful as many of us had hoped.

Chuck Dvorak

AT&T Labs Research

  _____  

Lars:

You are right. That is why, the QOS model like DiffServ comes into picture.

There is another aspect of these QOS models so far the standardization is
concerned. That is called interwoking between the different QOS modeling
standards. For example, you have mentioned as follows:

Recently, we also see some fertile brains have created some so-called
"Implementation-specific QOS schemes" that are based on "values" of all QOS
parameters. The fundamental problems are that they also called these as QOS
models (instead of saying that these are some QOS "implementation" schemes,
NOT QOS models). They have even convinced few folks here and there of
different standard organizations that they need "interworking" between
different QOS models.

Best regards,

Radhika

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 08:13:07 -0400

On Oct 19, 2006, at 7:43 AM, <[email-masked]> wrote:

> about

I don't see why you need this?
> 3) QoS models specify how to map to the baseline QSPEC.
I would rather say a QoS model says which of the constraint  
expressions it is capable of understanding and enforcing, and  
possibly some bounds on the constraints that the user had better not  
exceed or he risks his request deterministically failing admission  
control. For example, if the user specifies a deterministic upper  
bound of delay, a QoS model without the capability to enforce such a  
bound will reject the request. If he specifies a probabilistic upper  
bound as his constraint, any number of QoS models might be able to  
admit the traffic, depending on the particular resource availability  
and the granularity of the schedulers, and the maximum queue depths  
allowed.

> model mapped (or not) to domains support QoS models.
In my world view there is no mapping in the NSIS signaling. There is  
only local mapping at the points in the domain providing a given QoS  
capability to determine whether the traffic should be admitted. If we  
want to allow a domain to carry "domain private" stuff piggybacked on  
the NSIS signaling that's fine, and if we want to allow such domain  
private stuff to have a public schema ala "QoS models" I'm not  
opposed to that as long as we don't try to define common semantics  
across these "QoS models".

> Robert and Dave seem to agree that point 1) is not too far from the
I don't think the current QSPEC has parameters that directly express  
the constraints that I defined in (c).

I'll leave it to the WG if they think this is just too major surgery  
for this late in the game.

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 15:20:59 +0300

Dave,

See in-line:

>> I've been in transit for a few days, so trying to catch-up on all 
>> mails is somewhat challenging.  Here's a partially baked proposal, 
>> considering the mails on this thread.  My proposal for the WG to 
>> consider  is:
>>
>> encryption

See my comment after point 4.

>possibly some bounds on the constraints that the user had 
>better not exceed or he risks his request deterministically 
>failing admission control. For example, if the user specifies 
>a deterministic upper bound of delay, a QoS model without the 
>capability to enforce such a bound will reject the request. If 
>he specifies a probabilistic upper bound as his constraint, 
>any number of QoS models might be able to admit the traffic, 
>depending on the particular resource availability and the 
>granularity of the schedulers, and the maximum queue depths allowed.

This makes sense, as long as it is achievable with what people have been

planning on in their QoS Model work.
>In my world view there is no mapping in the NSIS signaling. 
>There is only local mapping at the points in the domain 
>providing a given QoS capability to determine whether the 
>traffic should be admitted. If we want to allow a domain to 
>carry "domain private" stuff piggybacked on the NSIS signaling 
>that's fine, and if we want to allow such domain private stuff 
>to have a public schema ala "QoS models" I'm not opposed to 
>that as long as we don't try to define common semantics across 
>these "QoS models".

This is what I meant by the secondary QSPEC.  It could be transparently
transmitted across other domains.

>I don't think the current QSPEC has parameters that directly 
>express the constraints that I defined in (c).
>
>I'll leave it to the WG if they think this is just too major 
>surgery for this late in the game.

Well, it seems that we need some amount of surgery to achieve this.
I don't think we can pass the documents onto the IESG with out rough
concensus.

John

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 15:24:56 +0300

Hi Janet,

What I mean is that there could be a way to transparently pass the QoS
Model QSPEC without mapping it to the baseline QSPEC.

John 

>From: ext Janet P Gunn [mailto:[email-masked]] 
>Sent: 19 October, 2006 15:00
>Cc: [email-masked]; [email-masked]
>Subject: Re: [NSIS] QSPEC proposal
>
>
>
>
>
>
>
>Can you please rephrase number 4?  I don't understand it the 
>way it is currently written.
>
>Thanks
>
>Janet
>
>
>> considering the mails on this thread.  My proposal for the 
>WG to consider  is:
>>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 19 Oct 2006 08:25:21 -0400

Again the same logic of generalization - Mixing "apples" with "oranges" when "interworking" is concerned!
 
Is it an isolated stand-alone debate that people will "just" look into Y.1541 value-based QOS class parameters all by itself?
 
If it is stand-alone Y.1541 value-based QOS implementations for using NSIS QOS signaling protocol why a separate stand-alone Y.1541-specific drat is not written? For example, people can "assume" a Y.1541 implementation-based QOS policy "somehow" does magic to do so. What is the problem?
 
People can "carry" any values of any parameters in NSIS QOS signaling protocol and, it could be 100s of any so-called QOS classes like Y.1541. It is NOT a rocket science.
 
Why then so-called Y.1541 QOS value-based implementation-specific model is drawn in the same level like that of non-value-based non-implementation-based DiffServ and RSVP for interworking? It will NEVER interwork.
 
Why do they need to be done in the same draft creating a problem of generalization between apples and oranges?
 
The issue is interworking of the QSPEC template carry the QOS parameters: Value-based and Non-Value-based.
 
Radhika

From: [email-masked] [mailto:[email-masked]]
Sent: Thu 10/19/2006 7:58 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

I've got to agree with Chuck on this.   How Y.1541 fufills QoS classes is not an NSIS issue.  I think it is clear how to carry them, but how the domain deploying Y.1541 verifies things are fufilled is outslide of NSIS.
 
John

	To: [email-masked]; [email-masked]; Loughney John (Nokia-NRC/Helsinki)

	Radhika

	Water and oil aside, the Y.1541 QoS classes are not "implementation-specific" as you say. They may use DiffServ, they may use RSVP, they may use something else. How is that implementation-specific?

	For me, this misunderstanding by you is the root cause of your criticism. (I understand your argument-I just do not agree with it, because it is inaccurate.)

	The Y.1541 classes are QoS classes that many experts around the world agreed capture, in a reasonably small number, distinct combinations of IP performance parameters capable of supporting virtually all user applications with the requisite QoS. On an e2e basis, a user may for example indicate "I am using IPTV and want to request Y.1541 Class 5, which would satisfy my QoS needs." Networks in the path may implement different QoS schemes (per-hop, per-domain, whatever), but a good NSIS method will still allow the e2e QoS classes (of Y.1541) to be addressed.

	But there is no effective way to signal this e2e today, and that is what many of us wanted NSIS to do-signal this e2e need, with enough hooks to be useful. 

	If all that is done in NSIS is to make incremental improvements to RSVP, or to focus primarily on signaling peak bandwidth needs, then IMO the end result will not be nearly as useful as many of us had hoped.

	Chuck Dvorak

	AT&T Labs Research

	Cc: [email-masked]; Georgios Karagiannis; [email-masked]; [email-masked]

	Lars:

	There is another aspect of these QOS models so far the standardization is concerned. That is called interwoking between the different QOS modeling standards. For example, you have mentioned as follows:

	Recently, we also see some fertile brains have created some so-called "Implementation-specific QOS schemes" that are based on "values" of all QOS parameters. The fundamental problems are that they also called these as QOS models (instead of saying that these are some QOS "implementation" schemes, NOT QOS models). They have even convinced few folks here and there of different standard organizations that they need "interworking" between different QOS models.

	Here the fundamental problems come. Who is kidding whom trying to mixing between water and oil? 

	Best regards,

	Radhika

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 19 Oct 2006 07:34:36 -0500

Hi Dave,

Many thanks for stepping in here.  Please see below. 

> Sent: Thursday, October 19, 2006 1:06 AM
> To: Lars Westberg
> Cc: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS; Georgios 
> Karagiannis; [email-masked]
> if they want to go back a couple of years in the archives they'll  

I recall the discussion quite well, and my understanding was that we
adopted your proposal as we understood it.  I could go back to the
threads but I recall no conclusion that what we have progressed is
contrary to any of your proposals.  Indeed, we would be unwise to not
follow your advice IMO.
 
> source's preferences for traffic handling (e.g. excess treatment)

I agree with Robert that the present qspec is mostly consistent and
aligned with a) -> d).  This is in fact what I recall you suggesting 2
years ago, and we had much discussion on the list as to how this was
being adopted in the qspec.  We may not have the mandatory/optional
split exactly as you envision, or the  specific suggestions in b), but
those things can be re-aligned better going forward.  

Thanks,
Regards,
Jerry

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 19 Oct 2006 07:35:21 -0500

Dave,
John,

Please see below. 

> Sent: Thursday, October 19, 2006 8:13 AM
> Subject: [NSIS] Re: QSPEC proposal
> 
> 
> > mails

I agree with the taxonomy, and believe the current qspec basically
aligns with a) --> d).  Details can be re-aligned as needed (e.g., add
the specifics in b).

> > mathematically complete.
 
> I don't see why you need this?

I agree with Dave, I don't see a need for a 'secondary QSPEC'.  Perhaps
you are referring here to stacking a 'local qspec' on top of an
initiator qspec, which is of course allowed in the current scheme of
things?  If not, please clarify what is a 'secondary qspec'.

> and the granularity of the schedulers, and the maximum queue depths  

I agree with Dave's characterization here of what QoS models should do.

> across these "QoS models".

I agree with Dave.  Most of the confusion and objection on this long
discussion is regarding 'remapping' qspec parameters.  In many (most)
cases there is no sensible 'remapping' from qspec parameter apple-1 to
qspec parameter orange-2.  We might consider defining only specific
allowed remappings (very few IMO) and leave it at that.

> for this late in the game.

Barring the above caveats on 2) and 4), I don't think this is major
surgery at this point.

Thanks,
Jerry

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 15:39:45 +0300

Dave & Jerry,

It would be great if you could propose a resolution to meet Dave's
'requirement.' It would be fine to discuss off-list and propose
something to move forward.

thanks,
John 

>From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>Sent: 19 October, 2006 15:35
>To: David R Oran
>> One more time from left-field (I know... I've lost this one 
>before and 
>> should keep my mouth shut).
>> 
>> A long time ago I proposed a different architectural 
>partitioning (and 
>> moving some things like priority outside the qspec entirely since it 
>> was a general admission control parameter and not a QoS 
>parameter). I 
>> won't resurrect the whole thing here but remind people if 
>they want to 
>> go back a couple of years in the archives they'll find the 
>outline of 
>> the proposal and the ensuing discussion. I shut up because the WG 
>> consensus was against my proposal and I'm not in the habit of 
>> continuing to make a pain of myself when I lose an argument.
>
>I recall the discussion quite well, and my understanding was 
>that we adopted your proposal as we understood it.  I could go 
>back to the threads but I recall no conclusion that what we 
>have progressed is contrary to any of your proposals.  Indeed, 
>we would be unwise to not follow your advice IMO.
> 
>I agree with Robert that the present qspec is mostly 
>consistent and aligned with a) -> d).  This is in fact what I 
>recall you suggesting 2 years ago, and we had much discussion 
>on the list as to how this was being adopted in the qspec.  We 
>may not have the mandatory/optional split exactly as you 
>envision, or the  specific suggestions in b), but those things 
>can be re-aligned better going forward.  
>
>Thanks,
>Regards,
>Jerry
>
>> explicitly in the last call and requesting comments, or 
>punting to the 
>> IESG to solicit such advice.
>>

---

From: Roland Bless <[email-masked]>
Date: Thu, 19 Oct 2006 14:42:37 +0200

Hi Dave,

> I don't see why you need this?

I don't understand that fully, too. Maybe it has to do with some
implicitly set parameters depending on the QoS model?

> I would rather say a QoS model says which of the constraint expressions
> it is capable of understanding and enforcing, and possibly some bounds
> on the constraints that the user had better not exceed or he risks his
> request deterministically failing admission control. For example, if the
> user specifies a deterministic upper bound of delay, a QoS model without
> the capability to enforce such a bound will reject the request. If he
> specifies a probabilistic upper bound as his constraint, any number of
> QoS models might be able to admit the traffic, depending on the
> particular resource availability and the granularity of the schedulers,
> and the maximum queue depths allowed.

Yep, and the details are up to the QoS model...

> capability to determine whether the traffic should be admitted. If we

Exactly!

> private stuff to have a public schema ala "QoS models" I'm not opposed
> to that as long as we don't try to define common semantics across these
> "QoS models".

Yep, which also seems to be not an easy task...
The advantage of the new proposal is that you only need a local
1:1 mapping instead of an n:1 mapping for n different services from
different QoS models. The current difficulties may stem from the fact
that we tossed all different parameter sets from different models
together and try to find a common denominator. I guess it's much harder
to map from <QoS Class> = <PHB Class> <Y.1541 QoS Class> <DSTE Class Type>
to my own QoS model rather than from Dave's proposed parameter set a)-d)
to my own.

> I don't think the current QSPEC has parameters that directly express the
> constraints that I defined in (c).
> 
> I'll leave it to the WG if they think this is just too major surgery for
> this late in the game.

I'd prefer to rethink the QSPEC approach along your proposal
and I guess it would be easier to support then...:-)

Regards,
 Roland

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 19 Oct 2006 08:52:52 -0400

Janet and John:
 
It seems to be an innocent proposal: "Transparent" passing of OQS classes using NSIS signaling protocol.
 
It depends.
 
It is not all so easy to pass "transparently" because they have some sort of dependency while the QOS parameters of the QSPEC template is concerned. There has to be a minimum level common understanding what can be transferred transparently what cannot be considering the heterogeneous models mainly of two classes: Value-based versus non-value-based.
 
So, the suggestion is this: Make two separate drafts: 1. Non-Implementation-specific non-valued-based (DiffServ, RSVP, IntServ) and 2. Implementation-specific value-based (Y.1541 and DSTE).
 
The second draft will be called implementation draft of NSIS QOS signaling protocol using Y.1541 and DSTE as they are value-based. It is not a standard.
 
For example, Dave already observed how RSVP using the "generalized" QOS parameters. 
 
Another key observation is this: If one uses some values of Y.1541 parameters in RSVP signaling messages, it will perfectly implement Y.1541 QOS classes for which no separate implementation draft or standardization is required. Please note that the opposite is NOT true. That is why so-called Y.1541 and DSTE QOS schemes are NOT QOS model. They are called implementation-specific QOS schemes (NOT "model").
 
So, why has NSIS WG so much headache to make a separate standard for carrying so-called implementation-specific value-based Y.1541 QOS parameters as it has been proposed about 2 years ago? NSIS QOS signaling messages can carry any values of any QOS parameters and, one set of values of those QOS parameters will represent Y.1541 QOS class. Same is the case for DSTE.
 
Can people convince anyone why people want a separate standard (?) in NSIS for carrying some "values" of some QOS parameters that are being used so-called Y.1541 QOS parameters? Who will restrict the users not to use some values as they like?
 
It is ridiculous to say that Y.1541 is a kind of a generalized QOS model!!!
 
I hope that it is clear to you all.
 
Best regards,
Radhika

From: [email-masked] on behalf of [email-masked]
Sent: Thu 10/19/2006 8:24 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] QSPEC proposal

Hi Janet,

John

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 19 Oct 2006 07:58:43 -0500

John and Dave, 

> Sent: Thursday, October 19, 2006 8:40 AM
> To: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Cc: [email-masked]

This would be fine by me.

Thanks,
Jerry

> >> under specification, what it means for a parameter to be 
> >> mandatory, 
> >> etc.
> >>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 19 Oct 2006 15:08:16 +0200

Hi John

I also still do not understand point 4)?

Is this relkated to the possibility of ignoring mandatory parameters?

How many mandatory parameters will then the base QSPEC have?
I assume that Dave, proposed to have one mandatory parameter and that is the

Token Bucket specification.

Best Regards,
Georgios

> Sent: donderdag 19 oktober 2006 14:25
> To: [email-masked]
> What I mean is that there could be a way to transparently 
> pass the QoS Model QSPEC without mapping it to the baseline QSPEC.
> 
> John 
>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 19 Oct 2006 09:18:41 -0400

Hi, Georgios and Dave:
 
Like you, all of us are also extremely worried to solve the fundamental problem as stated again and again as follows:
 
"The problem that remains to be solved is to find out how to interwork between the QoS models."

The only way is to solve the interworking between different QOS models, we need to do deep "surgery" of our understanding what we mean by QOS models in the first place.
 
What properties of a QOS model make it a QOS model? In my other emails, I have clarified this. Let me try again.
 
We have DiffServ, RSVP, and IntServ QOS models. These QOS models interwork among themselves. What are the properties of these QOS models?
 
We have another set of so-called QOS implementation schemes: Y.1541 and DSTE. They even do NOT interwork among themselves. What are the properties of these two? Are these two represent QOS models? If so, why do they qualify for being QOS models?
 
The key is this: If one put some specific values in RSVP QOS parameters, one cane easily get all so-called QOS classes implemented, for example, people will get Y.1541 and DSTE implementations.
 
The question is this: How do you interwork between non-implementation-specific non-value-based (DiffServ, RSVP, IntServ) and implementation-specific value-based (Y.1541 and DSTE) system?
 
It is a problem of mixing between "apples" and "oranges." The technical miracle will NEVER happen just because Dave have made one high level proposal. Let us not dance around this proposal yet unless it solves the interworking problems of QOS models.
 
The clear proposal is this as articulated in earlier email: Make two separate drafts - 
 
1. Non-implementation-specific non-value-based (DiffServ, RSVP, IntServ) and 
2. Implementation-specific value-based (Y.1541 and DSTE)
 
Best regards,
Radhika

From: [email-masked] on behalf of Georgios Karagiannis
Sent: Thu 10/19/2006 7:41 AM
To: 'David R Oran'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Hi Dave

 Please see in line!

Georgios:

What do you think?

Best regards,
Georgios

---

From: Lars Westberg <[email-masked]>
Date: Thu, 19 Oct 2006 15:19:23 +0200

comment inline

> I think it is not a good idea.

Mandating one single parameter se into the core NSIS-specification seems 
not a good idea. 
In reality, I would rather prefer to include this as topic into a 
re-chartering of the working group.

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 09:25:06 -0400

> Token Bucket specification.
I still think we are talking past each other. Please tell me which of  
the following is your intended definition of "mandatory"
w) must be present in any QSPEC formulated by the end user
x) must be understood by every QOS NSLP-capable network element in  
the universe
y) must result in admission control success in any NSLP-capable  
network element that has sufficient resources to comply with the  
specified value by the user.

My preferred formulation is actually none of the above.

1. that only the TSPEC-like parameters in my traffic description  
proposal be mandatory in the sense that your request is syntactically  
invalid if they are not present.
2. That all the traffic description in my (b) category be optional  
both for inclusion and for interpretation by the network elements.
3. That for the constraint parameters, we explicitly encode in the  
protocol whether the user wants to have admission control succeed  IF  
AND ONLY IF the parameter is understood, and the constraint  
satisfied, by each QOS NSLP-capable network element on the signaling  
path. I do not like the ideaq of statically binning the constraint  
parameters in architectural "mandatory/optional" categories.

Cheers, Dave.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 19 Oct 2006 09:30:53 -0400

Chuck:
 
You just "remove" the "values" of the parameters of Y.1541. All bubbles of Y.1541 will burst in the air. 
 
If you use those some specific values in RSVP, you can get all the Y.1541 QOS classes implemented in it, but not vice versa.
 
You can easily see what QOS properties Y.1541 has.
 
When something is based on specific values it is called implementation-specific.
 
Any implementation can be mapped to RSVP and DiffServ. That does not mean implementations are QOS standards.
 
Best regards,
Radhika
 
PS: Experts of the whole world will always be using Y.1541 for implementations. Pl. advise them to express their opinions for all emails that I have sent in the IETF mailing list. Otherwise, you can send them all the emails that I sent. Let them read it and participate in the IETF mailing list. Unlike ITU-T and 3GPP, this mailing list is open to all.

From: [email-masked] [mailto:[email-masked]]
Sent: Wed 10/18/2006 8:15 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Radhika

Chuck Dvorak

AT&T Labs Research

Lars:

Best regards,

Radhika

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 19 Oct 2006 15:34:14 +0200

Hi Dave

By mandatory I mean:
x) must be understood by every QOS NSLP-capable network 
element in the universe

The current QSPEC template specification defines:
13 parameters that "must be understood by every QOS NSLP-capable network 
element in the universe"

My question is:
Is your proposal refering only to one parameter, i.e., Token Bucket that
"must be understood by every QOS NSLP-capable network 
element in the universe"?

Best regards,
Georgios

> Sent: donderdag 19 oktober 2006 15:25
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; [email-masked]
> > I assume that Dave, proposed to have one mandatory 
> parameter and that 
> > is the
> >
> I still think we are talking past each other. Please tell me 
> which of the following is your intended definition of "mandatory"
> x) must be understood by every QOS NSLP-capable network 
> element in the universe
> y) must result in admission control success in any 
> NSLP-capable network element that has sufficient resources to 
> comply with the specified value by the user.
> 
> 1. that only the TSPEC-like parameters in my traffic 
> description proposal be mandatory in the sense that your 
> request is syntactically invalid if they are not present.
> 2. That all the traffic description in my (b) category be 
> optional both for inclusion and for interpretation by the 
> network elements.
> 3. That for the constraint parameters, we explicitly encode 
> in the protocol whether the user wants to have admission 
> control succeed  IF AND ONLY IF the parameter is understood, 
> and the constraint satisfied, by each QOS NSLP-capable 
> network element on the signaling path. I do not like the 
> ideaq of statically binning the constraint parameters in 
> architectural "mandatory/optional" categories.
> 
> Cheers, Dave.
> 
> 
> > Best Regards,
> > Georgios
> >
> >
> >
> >
> >
> >> What I mean is that there could be a way to transparently pass the 
> >> QoS Model QSPEC without mapping it to the baseline QSPEC.
> >>
> >> John
> >>

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 09:52:44 -0400

> 13 parameters that "must be understood by every QOS NSLP-capable  
yes. that's a bug in my opinion.

> element in the universe"?
Yes, with the proviso that I think the user needs the flexibility to  
control whether he wants admission control to fail if a constraint  
can't be satisfied due to the path going through something that  
doesn't understand the parameter. Reread what I wrote below.

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 19 Oct 2006 10:17:04 -0400

> Janet and John:

Oh dear- the connotations!

Janet

---

From: <[email-masked]>
Date: Fri, 20 Oct 2006 12:36:47 -0400

For me this is definitely NOT about value-based vs. non-value based, it is more about the fact that e2e QoS is not the same as, for example, node-specific performance (e.g., PHBs).

We gave this a lot of thought in Y.1541, which gives examples of how DiffServ PHBs can be used to address certain Y.1541 e2e QoS classes. For example, if an application requiring interactivity is to be supported, certain e2e QoS is needed (low delay), which translates into specific Y.1541 classes, supportable by EF DSCPs. One would thus want an NSIS QoS protocol to help use nodal behavior to support e2e QoS needs.

BTW note that I did not say a thing about bandwidth. (Focusing on only bandwidth is really missing all of what I thought NSIS was going to do!)

Chuck 

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 19, 2006 8:25 AM
To: [email-masked]; Dvorak,Charles A (Chuck); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

 

 

Radhika

________________________________________
 
John