Subject: [NSIS] About the QSPEC 1 vs. 2 discussion

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 8 Oct 2006 22:30:39 +0300 (EEST)

Hi all,

I went through again the long discussion about QSPEC- vs. QSPEC-2. In 
order to get people's opinions, it might be good for Jerry as the QSPEC 
editor to summarize what is being discussed. ( I think the discussion 
ended after Rudi's comment :) ).

Still, two thoughts about the discussion (I may not have understood all, 
though):

A) How come a QNI making a resource request can dictate (<Excess 
Treatment>, QSPEC-1) what the network does if the QNI sends illegal 
amounts of traffic? How come if I make a reservation for 1 Mbps, and then 
send more than that, I can still ask the network something? If I was a 
network operator (luckily for us all I'm not ;), I'd drop all packets from 
the node that tries to send more than it requested resources for. Thus, I 
think the <Excess Treatment> should be QSPEC-2, at most.

B) For the other QSPEC-1 parameters, how can a QNI figure out, e.g., what 
QoS class its flow should be, if it is making a Controlled Load 
reservation? Where do I get this information? I want just bandwidth, I 
don't know anyting about DiffServ or any other class-based schemes.

Thus, I'd rather see <Excess Treatment> as more of an optional hint a node 
can give. And for the other QSPEC-1 parameters, hopefully I don't need to 
figure out values for them if I don't (want to) understand them.

Regards,
Jukka

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Sun, 8 Oct 2006 18:38:33 -0400

Hi, Jukka:
 
I appreciate that you are trying to solve the problems of QSPEC. I am reacting with reference to QOS Classes of QSPEC as referred in your email.
 
However, do you ever recognize the two fundamental things that contradict in mapping/interoperability in  NSIS QOS as follows:

1.	
	Parameters that can take any values.
2.	
	Parameters that have been "hard-coded" with "specific" values.

The whole NSIS QOS signaling specification is based on item 1.

If so, why are we muddling with only two items in QSEPC that deal with item 2? These items in QSPEC are as follows:

*	Y.xxxx QOS Classes and DSTE QOS classes. 
*	Unlike DiffSev, RSVP, and other QOS schemes these QOS classes are based on item 2 as mentioned above.

If these two QOS classes, Y.xxxx QOS Classes and DSTE QOS, would have been based on say "GOLD, SILVER, COPPER, or similar to those of like item 1, there would have been no so much problems for interworking/mapping in NSIS signaling schemes.

What are those Y.xxxx QOS Classes and DSTE QOS classes are based on some "hard-coded" specific values line 50-ms, 100-ms, 150-ms, etc and not like bandwidth, delay, jitter, or packet loss.

How can one map/interwork between 50-ms class 1 (say Y.xxxx) and 75-ms class Y (say DSTE)?

Had those QOS classes like RSVP parameters been like "Guaranteed," "Controlled," or "Best-Effort," could we not solve these problems of mapping/interworking easily? If so, why are we not dropping those "peculiar" QOS classes from the QSPEC spec?

If needed, separate drafts can be written to deal with these Y.xxxx QOS Classes and DSTE QOS classes in NSIS QOS protocol. There is no hurry for the IETF to deal with this now in the NSIS WG.

I would appreciate your response to deal with these problems.

Best regards,

Radhika

________________________________

From: [email-masked] on behalf of Jukka MJ Manner
Sent: Sun 10/8/2006 3:30 PM
To: [email-masked]
Subject: [NSIS] About the QSPEC 1 vs. 2 discussion

Hi all,

Regards,
Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 10 Oct 2006 10:11:37 +0300 (EEST)

Hi,

If I understood you correctly, you are suggesting to remove the classes 
from the list of mandatory parameters?

My point is a bit similar, what I would like to be clearly specified is, 
what value do I put in a QoS class object if I don't know anything about 
classes? The same goes with priority. The QoS Template should tell me what 
would be e.g. default values to put in case the application doesn't care, 
nor understand, anything about classes - or priority, too. 

Maybe the answer is, "If you don't know, then mark every flow as best 
effort." (and low priority)? If that is the case, then why would I use a 
QoS class object in the first place, just to consume bits on the wire.

Jukka

---

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

Jukka,

> what I would like to be clearly specified is, 
> what value do I put in a QoS class object if I don't know
> anything about classes? The same goes with priority. The
> QoS Template should tell me what would be e.g. default
> values to put in case the application doesn't care, 

As has been said many times on this thread, the QSPEC -1 concept
requires that a QSPEC-1 parameter either be a) strictly interpreted, or
b) remapped (as specified in the QOSM specification document).  

There was clear consensus to retain the QSPEC-1 concept and the 4
QSPEC-1 parameters specified.
  
A QNI will not populate a QSPEC-1 (or QSPEC-2) parameter if it doesn't
use it.  If it uses it, it knows how to populate it.

I don't think you are bringing anything new to the table in this
discussion, only rehashing what has been said before.

Jerry

---

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

Hi Jerry

>From my point of view there was no consensus on what you are saying!

Best Regards,
Georgios

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: dinsdag 10 oktober 2006 10:47
> To: Jukka MJ Manner
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion
> 
> Jukka,
> 
> > what I would like to be clearly specified is, what value do 
> I put in a 
> > QoS class object if I don't know anything about classes? 
> The same goes 
> > with priority. The QoS Template should tell me what would be e.g. 
> > default values to put in case the application doesn't care, nor 
> > understand, anything about classes - or priority, too.
> 
> As has been said many times on this thread, the QSPEC -1 
> concept requires that a QSPEC-1 parameter either be a) 
> strictly interpreted, or
> A QNI will not populate a QSPEC-1 (or QSPEC-2) parameter if 
> it doesn't use it.  If it uses it, it knows how to populate it.
> 
> I don't think you are bringing anything new to the table in 
> this discussion, only rehashing what has been said before.
> 
> Jerry
>

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 10 Oct 2006 12:24:43 +0300 (EEST)

Jerry,

Would you kindly provide the rationale to why excess traffic handling is 
something a QNI should mandate the network to do? Sounds a bad idea in the 
first place.

Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 10 Oct 2006 13:07:08 +0300 (EEST)

I went through, again, the QSPEC Template draft. The main concern I have 
is that the spec is somewhat unclear about the processing of QSPEC-1 
paremeters. The important information is here and there, but you really 
need to look for it.

One of the critical aspects to really understand is that even though a QNE 
does not support a QSPEC-1 parameter, it can just decide to ignore or 
remap it. This is _not_ a critical error, the QNI will eventually get to 
know that not all nodes on the path support the QNI's wishes, but the 
reservation was still succesful. So, at the end, the only difference 
between QSPEC-1 and QSPEC-2 are, when a QNE does not support the object:

- QSPEC-1: raise a flag, and continue as if all is well, the QNI will get 
  to know this, and decide how much it wants exactly what was 
  signaled. 

  The question here is, what can it do then? If I ask some bandwidth, and 
  some node on the path does not understand it, then how do I know which 
  QoS Class to use, then?This is a similar case than we have had 
  discussions on with the QoS NSLP error signaling with a tear.

- QSPEC-2: A QNE can just skip it, if it doesn't like it. QNI will never 
  know.

Some examples would help a reader a lot, e.g., some scenario, where the 
e2e path includes different QoS Models: what happens on the edges of 
domains, what flags/bits are set when/where/why, and what will the QNI 
eventually get as reply? What can the QNI do, if something was 
remapped/skipped?

Jukka

---

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

Jukka,

> Would you kindly provide the rationale to why excess traffic
> handling is something a QNI should mandate the network to do?
> Sounds a bad idea in the first place.

I don't see any problem RE excess treatment.  E.g., if a QNI specifies
bandwidth I don't see what possible problem there might be in specifying
excess treatment?

Please note that a QNI does *not* have to populate excess treatment if
its QOSM doesn't use it.

Jerry

---

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

> If I ask some bandwidth, and some node on the path does not understand
> it, then how do I know which QoS Class to use, then?

If QoS Class is not populated by the QNI in the initiator QSPEC, then a
QNE has nothing to decide.  If QoS class is populated, the QNE knows
what to decide.

> Some examples would help a reader a lot, e.g., some scenario, where
> the e2e path includes different QoS Models: what happens on the
> edges of domains, what flags/bits are set when/where/why, and what
> will the QNI eventually get as reply? What can the QNI do, if
> something was remapped/skipped?

See Appendix A.

Jerry

---

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

Hi Jerry
 
Please see below!

> Sent: dinsdag 10 oktober 2006 12:14
> To: Jukka MJ Manner
> If QoS Class is not populated by the QNI in the initiator 
> QSPEC, then a QNE has nothing to decide.  If QoS class is 
> populated, the QNE knows what to decide.

Georgios: How the QNE knows what to decide?
 Suppose that the QNE is a diffserv node and it receives a 
<Y.1541 QoS Class> parameter.

> > the e2e path includes different QoS Models: what happens on 
> the edges 
> > of domains, what flags/bits are set when/where/why, and 
> what will the 
> > QNI eventually get as reply? What can the QNI do, if something was 
> > remapped/skipped?
> 
> See Appendix A.
> 
> Jerry
>

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 10 Oct 2006 13:22:54 +0300 (EEST)

> > something was remapped/skipped?

That is a 4.5 page example, at the end of the spec as an appendix. What is 
needed, is a short, simple, example at the very beginning of the spec, 
where the concepts are introduced.

Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 10 Oct 2006 13:35:53 +0300 (EEST)

In my example, "I" meant QNI.

The main point is the spec should give the reader some ideas on what the 
QNI can do, if its request (some of the QSPEC-1 parameters) was not fully 
accepted. Is there anything the QNI can do?

Jukka

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Tue, 10 Oct 2006 15:51:49 +0200

Hi All, we had extensive discussions regarding this issue and we did not reach a consensus. I think it is less important what QNI includes. The main question here is that Qspec 1 parameters must be implemented in all NSIS node. So in the current description an NSIS node must implement Diffserv, DSTE, Y.1541 QoS classes, different priorities and excess treatment. Are we happy with this?

Best regards, Attila

>From: Georgios Karagiannis [mailto:[email-masked]] 
>Sent: Tuesday, October 10, 2006 12:19 PM
>To: 'Ash, Gerald R (Jerry), ALABS'; 'Jukka MJ Manner'
>Cc: [email-masked]
>QSPEC, then 
>> a QNE has nothing to decide.  If QoS class is populated, the 
>QNE knows 
>> what to decide.
>

---

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

What a funny thing:
 
".NSIS node must implement ...DSTE, Y.1541 QoS classes, .. "
 
Why it is so?
 
How the values (e.g., 50-ms class 1 of so-called Y.xxxx) of one QOS class can interwork with another (e.g., say 100-ms class Y of so-called DSTE) QOS class for implementation?
 
Are people comparing apples with oranges: One set of parameters are based on values (e.g., so-called Y.xxxx, DSTE) and another set of parameter based on without values (e.g., DiffServ)?
 
It speaks for itself what is going on ... Are we going on circle?
 
BR/Radhika

From: [email-masked] on behalf of Attila Báder (IJ/ETH)
Sent: Tue 10/10/2006 9:51 AM
To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Jukka MJ Manner
Cc: [email-masked]
Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion

Best regards, Attila

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 10 Oct 2006 20:05:33 +0300 (EEST)

Hi Attila,

I think that is not what the spec says, really. If I read the (unclear) 
spec right, a QoS Model does not need to make use of QSPEC-1 parameters. 
It only needs to be able to parse them, and say "I'm going to ignore this" 
by writing a flag in the object.

Section 5 says:

"In this document the term 'interpret' means, in relation to RMF
 processing of QSPEC parameters, either that the RMF a) strictly
 interprets a QSPEC parameter, or b) remaps, approximates, or
 otherwise does not strictly interpret the parameter."

Thus, a QNE running a certain QoS Model can decide to "remap to NULL" or 
"approximate to NULL" or "not strictly interpret = just skip".

So, basically, there is very little difference in practise between QSPEC-1 
and QSPEC-2 parameters. That is one of things that leaves we wonder why 
the spec is as it is.

Jukka

On Tue, 10 Oct 2006, Attila Báder (IJ/ETH) wrote:

> Hi All, we had extensive discussions regarding this issue and we did not 
> reach a consensus. I think it is less important what QNI includes. The 
> main question here is that Qspec 1 parameters must be implemented in all 
> NSIS node. So in the current description an NSIS node must implement 
> Diffserv, DSTE, Y.1541 QoS classes, different priorities and excess 
> treatment. Are we happy with this?
> 
> Best regards, Attila
> 
>

---

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

> "approximate to NULL" or "not strictly interpret = just skip".

'Remap to NULL', 'just skip', or otherwise 'ignore' QSPEC-1 parameters
is *not* allowed, as is spelled out in the current document. 

> and QSPEC-2 parameters. That is one of things that leaves we wonder
why 

Not so.  QSPEC-1 must be interpreted if populated, QSPEC-2 can be
ignored if populated.

Jerry

---

From: <[email-masked]>
Date: Wed, 11 Oct 2006 06:14:44 +0300

Hi all,

I've tried to go through the volumes of mail on this the open issues,
and it is quite 
confusing to try to figure out any sort of consensus.  The lack of
formal issues
being filed with suggested text and lack error tracking has contributed
to the
unclear situation.  Finally, most of the discussion is quite circular,
which has
not be helpful either.

In order to come to consensus, I ask everyone with any open concerns on
the QSPEC
draft to file an issue in the format below by close of business on
Friday. I will then
ask the QSPEC authors to consider the issue and look at resolving it,
and see
if there is consensus that I can then call.  I expect this should take
next
week to resolve.  After this, I think we will be able to complete this
draft.

Issue submission format:

Description of issue
Submitter name: Your_Name_Here
Submitter email address: Your_Email_Address_Here
Date first submitted: Insert_Date_Here
Reference: URL to e-mail describing problem, if available
Comment type: ['T'echnical | 'E'ditorial]
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Insert_Section_Number_Here
Rationale/Explanation of issue:
Length description of problem

Requested change:
Proposed changes to the document. Please be specific about what text you
want to change, 
add or delete. Issues cannot be considered until specific text is
provided.

thanks,
John

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 11 Oct 2006 12:56:09 -0400

John,

Is there a mechanism by which we can say that we concur that something
(raised by someone else) is an issue, without having to fully document the
issue again?

Janet

---

From: <[email-masked]>
Date: Wed, 11 Oct 2006 20:06:02 +0300

If you agree with an issue, just respond to the issue stating that you
agree
(or even disagreeing).

This is a very good thing to do and helps me to judge consensus.

thanks,
John

>From: ext Janet P Gunn [mailto:[email-masked]] 
>Sent: 11 October, 2006 19:56
>To: Loughney John (Nokia-NRC/Helsinki)
>Cc: [email-masked]
>Subject: Re: [NSIS] Resolving discussion on the QSPEC document
>
>
>
>
>
>
>John,
>
>Is there a mechanism by which we can say that we concur that 
>something (raised by someone else) is an issue, without having 
>to fully document the issue again?
>
>Janet
>
>
>> and it is quite confusing to try to figure out any sort of 
>consensus.  
>> The lack of formal issues being filed with suggested text and lack 
>> error tracking has contributed to the unclear situation.  Finally, 
>> most of the discussion is quite circular, which has not be helpful 
>> either.
>>
>> In order to come to consensus, I ask everyone with any open concerns 
>> on the QSPEC draft to file an issue in the format below by close of 
>> business on Friday. I will then ask the QSPEC authors to 
>consider the 
>> issue and look at resolving it, and see if there is consensus that I 
>> can then call.  I expect this should take next week to 
>resolve.  After 
>> this, I think we will be able to complete this draft.
>>
>> Issue submission format:
>>
>> Description of issue
>> Submitter email address: Your_Email_Address_Here Date first 
>submitted: 
>> Insert_Date_Here
>> Reference: URL to e-mail describing problem, if available Comment 
>> type: ['T'echnical | 'E'ditorial]
>> Proposed changes to the document. Please be specific about what text 
>> you want to change, add or delete. Issues cannot be considered until 
>> specific text is provided.
>>
>> thanks,
>> John
>>