Subject: RE: [NSIS] Alternatives for supporting domain-local admission controloperation in NSLP/QSPEC

From: Al Morton <[email-masked]>
Date: Mon, 20 Nov 2006 12:06:36 -0500

It seems to me there is benefit in keeping the Y.1541 class
in the QSPEC, because the Available class number could be modified along
the reservation path. Even if the individual parameters change
in the "QoS Available", it would be important recognize that a
(for example, delay) threshold has been crossed and that a lesser class
is now all that is available. This seems consistent with:

>    QoS Available: QSPEC object containing parameters describing the
>    available resources.  They are used to collect information along a
>    reservation path.

(I had wanted to make this comment during the meeting, but
was busy taking notes for my friend, Hannes)

Al

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 20 Nov 2006 13:20:56 -0500

All:
 
Again, it is the same problems to do any extensions that relates to value-based implementation-specific "non-standard" QOS SLAs like Y.1541, DSTE, and 3GPP/Y1541 in this "generic" QSPEC RFC.
 
However, if any parameter in "QOS Available" template is "generic" enough and does NOT mention anything-specific to Y.1541, DSTE, and 3GPP/Y1541 and is useful for the IETF standard QOS models like RSVP, DiffServ, and IntServ, it may then be considered.
 
All QOSM draft are there. These drafts and any implemetation-sepcific drafts for each QOS model that show some examples or even extensions of the "generic" QSPEC RFC can be used need to be produced separately.
 
Best regards,
Radhika

________________________________

From: [email-masked] on behalf of Al Morton
Sent: Mon 11/20/2006 12:06 PM
To: [email-masked]
Subject: RE: [NSIS] Alternatives for supporting domain-local admissioncontroloperation in NSLP/QSPEC

Al

---

From: <[email-masked]>
Date: Thu, 23 Nov 2006 09:55:10 +0200

Hi all,

>It seems to me there is benefit in keeping the Y.1541 class in 
>the QSPEC, because the Available class number could be 
>modified along the reservation path. Even if the individual 
>parameters change in the "QoS Available", it would be 
>important recognize that a (for example, delay) threshold has 
>been crossed and that a lesser class is now all that is 
>available. This seems consistent with:
>
>(I had wanted to make this comment during the meeting, but was 
>busy taking notes for my friend, Hannes)

At this point, I don't think I have seen any strong consensus for
keeping
the Y.1541 class in the QSPEC. I think it would be useful when Y.1541
QoS
models are involved in the e2e signaling, but its use as a general QoS
parameter is debatable.  Additionally, I don't think there has been
support
for this from other QoS models, nor many people speaking up in favor for
keeping this as a general parameter.

John

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 23 Nov 2006 07:59:44 -0600

Hi John,

Happy Thanksgiving (for U.S. people anyway)! 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, November 23, 2006 2:55 AM
> To: Morton, Alfred C, JR (Al), ALABS; [email-masked]
> Subject: RE: [NSIS] Alternatives for supporting 
> domain-localadmissioncontroloperation in NSLP/QSPEC
> 
> Hi all,
> 
> >>    available resources.  They are used to collect information along
> >>    a reservation path.
> >

> keeping the Y.1541 class in the QSPEC. I think it would be useful when
> Y.1541 QoS models are involved in the e2e signaling, but its use as a
> general QoS parameter is debatable.  Additionally, I don't think there
> has been support for this from other QoS models, nor many people
> speaking up in favor for keeping this as a general parameter.

I'll of course abide by your call here, and also remove <PHB Class> and
<DSTE Class Type> as per Roland's suggestion.  I'll note however

1. These parameters have been included in the QSPEC document from the
beginning, that is, from the -00 version over 2 years ago.
2. The document passed WGLC last February with these parameters in; IMO
that is consensus to leave in.
3. We just recently had the suggestion to remove these parameters, and
maybe 2 votes of support; it doesn't seem like a strong consensus to
remove.
4. Removing these parameters seems counter to support for DiffServ, as
originally mandated for the QSPEC, especially removing <PHB Class>.

Thanks,
Regards,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 24 Nov 2006 10:31:47 +0100

Hi Jerry

What about my proposal, sent in a previous e-mail!

"But the QSPEC template draft is not a generic QSPEC draft.
The Token Bucket and the constraints can be seen as something that can be 
common and can be used for the interoperability and the rest of the 
encoded parameters can just be used as guidelines on how the QoS 
models can encode their parameters.

Thus maybe Jerry could separate the QSPEC template draft into:
A section/part that describes the Token Bucket + constraints. 
This part could then emphasize that the described parameters 
can be used for interoperability purposes.

Another part of the QSPEC template draft will describe 
the other parameters.

The goal of this part is to provide guidelines to QoS models 
on how to encode the different parameters, with the currently 
available parameters used as examples."

Best Regards,
Georgios

> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: donderdag 23 november 2006 15:00
> To: [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS; Morton, Alfred C,JR (Al), 
> ALABS; [email-masked]
> Subject: RE: [NSIS] Alternatives for 
> supportingdomain-localadmissioncontroloperation in NSLP/QSPEC
> 
> Hi John,
> 
> > >It seems to me there is benefit in keeping the Y.1541 class in the 
> > >QSPEC, because the Available class number could be 
> modified along the 
> > >reservation path. Even if the individual parameters change in the 
> > >"QoS Available", it would be important recognize that a 
> (for example, 
> > >delay) threshold has been crossed and that a lesser class 
> is now all 
> > >that is available. This seems consistent with:
> > >
> I'll of course abide by your call here, and also remove <PHB 
> Class> and <DSTE Class Type> as per Roland's suggestion.  
> I'll note however
> 
> 1. These parameters have been included in the QSPEC document 
> from the beginning, that is, from the -00 version over 2 years ago.
> 2. The document passed WGLC last February with these 
> parameters in; IMO that is consensus to leave in.
> 3. We just recently had the suggestion to remove these 
> parameters, and maybe 2 votes of support; it doesn't seem 
> like a strong consensus to remove.
> 4. Removing these parameters seems counter to support for 
> DiffServ, as originally mandated for the QSPEC, especially 
> removing <PHB Class>.
> 
> Thanks,
> Regards,
> Jerry
>

---

From: Roland Bless <[email-masked]>
Date: Fri, 24 Nov 2006 10:36:29 +0100

Hi Jerry,

> that is consensus to leave in.

You are somewhat right, but
absence of comments is not consensus. However, I guess that the
situation changed when Dave Oran kicked in.

> maybe 2 votes of support; it doesn't seem like a strong consensus to

I guess that I'm amongst the 2 votes.

> originally mandated for the QSPEC, especially removing <PHB Class>.

I don't want to repeat here what I already said in a previous mail,
but signaling a PHB class has usually only real significance within
a DiffServ domain, but not between domains.
Actually, if there is consensus to leave the Y.1541 class in:
what is the procedure if the mapping from the generic (available)
parameters doesn't correspond to the class? Which specification
takes precedence?

Regards,
 Roland

---

From: Al Morton <[email-masked]>
Date: Fri, 24 Nov 2006 09:16:37 -0500

At 04:36 AM 11/24/2006, Roland Bless wrote:
>...Actually, if there is consensus to leave the Y.1541 class in:

Hi Roland,

The mapping seems straightforward to me, but perhaps I've
misunderstood your question. Let me give a brief example
to see if we are using the term "mapping" the same way.

A key point first:  The numerical objectives in the Y.1541
classes are upper bounds on performance. So, the mapping is
really a comparison between the current level of each
performance metric and the upper bound.

This example is based on latency alone:
Say that the Desired Y.1541 class = 0, which has a
latency bound of <=100ms. While the available latency meets
this bound, the available Y.1541 class = 0.

At some point along the path, the available latency is
found to be 120ms. The available Y.1541 class must change
to class = 1, because the 100ms latency bound of class 0
has been exceeded. This may be a significant change for
some users.

In general, the available Y.1541 class is the most demanding
class that can be met by the available performance.

Hope this helps, (and if not, I'll be glad to try again)
Al

---

From: Roland Bless <[email-masked]>
Date: Fri, 24 Nov 2006 17:15:54 +0100

Hi Al,

thanks for your answer. My comments inline.

> performance metric and the upper bound.

Yes, I'm aware of this. However, intermediate systems
must know the exact values in order to reserve an appropriate
amount of resources, e.g., in your example the current actual
admitted latency.

> this bound, the available Y.1541 class = 0.

Yep.

> has been exceeded. This may be a significant change for

Sure and that's why it should be rejected at this point.
But I guess that the available class is not allowed to be
"changed", because the constraints of that class cannot
be met anymore. In this case it only makes sense to
reject the request (it is not useful to continue with
saying available class=1).

The question I had is:
What about a situation where the QSPEC requests class 0,
but the requested latency upper bound is 150ms ("wrong" mapping)?

> class that can be met by the available performance.

That doesn't make sense to me. The class specifies the limits.
So if you cannot meet class 0, then you have to reject the
reservation. It makes no sense to continue the reservation with class 1.
If your application is also satisfied with class 1 it should
say so in its original request.

Furthermore, what about a domain that is able to provide you a
delay of 80ms (would map to class 0), though you requested
only class 1? I guess that a QNE should not change the available
class to 0 in this case.
Possibly there are currently only a few users in
that class 1, so that you get a really low latency service
although you didn't ask for one?
However, traffic for class 0 may be handled by a really
different DiffServ DSCP than that for class 1, i.e. resources
are effectively separated (though they both may use the EF PHB)
within a Y.1541 domain. The major point I see is that the
domain must decide in which of its traffic classes it performs
resource-based admission control. So a boundary QNE should not
follow blindly the available class value, it always has to
check the real values...

> Hope this helps, (and if not, I'll be glad to try again)

Thanks for the example, but it generated actually more questions
on my side :-)

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Fri, 24 Nov 2006 17:29:35 +0100

Hi Georgios,

see comments inline.

> Another part of the QSPEC template draft will describe 

As I said at the meeting:
the current QSPEC template draft actually contains both aspects
since we started with the template idea first and then added the
interoperability aspects. An even cleaner separation would be
a split into two separate documents:
- one (template focus) explaining the general idea and layout of QSPECs,
  which could be used by other QoS models as guidance to create their
  own QSPECs, and
- one (interoperability aspects) proposing a generic QSPEC as
  an example of a QSPEC instance
However, it's also ok for me to describe both aspects in one document
as it is probably now too late and too disturbing to make this
separation.

Regards,
 Roland

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sat, 25 Nov 2006 06:44:47 -0600

Hi Roland, Georgios,

See below. 

> From: Roland Bless [mailto:[email-masked]] 
> Sent: Friday, November 24, 2006 11:30 AM
> To: Georgios Karagiannis
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; 
> Morton, Alfred C, JR (Al), ALABS; [email-masked]
> Subject: Re: [NSIS] Alternatives for 

OK, Georgios' proposal sounds like a good compromise.

Thanks,
Regards,
Jerry

---

From: "Roy, Radhika R." <[email-masked]>
Date: Sun, 26 Nov 2006 16:49:48 -0500

Ronald and Georgios:
 
Why is it too late to clean out the document as Ronald has explained?
 
NSIS WG in particular and IETF in general have waited almost two years to root out these "technically" inconsistencies. It is better NOT to publish a standard track RFC like this.
 
If needed, NSIS WG Chair needs to appoint a "single" EDITOR who can clean out this document.
 
Why does the NSIS WG Chair need to appoint 3 (Three) editors?  Is it not the problems of appointing 3 editors for the same simple RFC? Is it not because of 3 editors who have put those things defying a "simple" common sense that to keep the document is the most important thing from the IETF point of view?
 
Is it not that people still trying to force so-called QOS SLAs like Y.1541, DSTE, and 3GPP/Y.1541 in this draft as "standard" QOS models?
 
A question to Georgios: Would you please provide any technical justifications why so called "non-standard" QOS SLAs like Y.1541, DSTE, and 3GPP/Y.1541 in this "standard" track RFC in the same level of IETF "standard-based" RSVP, IntServ, and DiffServ QOS Model? Is it not mixing between "apples" and "oranges?"
 
If Georgios cannot justify the above, references of so called "non-standard" QOS SLAs like Y.1541, DSTE, and 3GPP/Y.1541 as even examples for encoding of QSPEC parameters must NOT be included.
 
If it is done despite objections, we would think that this QSPEC RFC must NOT be a "standard" track RFC because a standard track RFC must NOT contain "non-standard" QOS models. This will also be brought to the notice of the NSIS WG Chairs and IESG.
 
Best regards,
Radhika

From: [email-masked] on behalf of Ash, Gerald R (Jerry), ALABS
Sent: Sat 11/25/2006 7:44 AM
To: Roland Bless; Georgios Karagiannis
Cc: [email-masked]; Ash, Gerald R (Jerry), ALABS; Morton, Alfred C, JR (Al), ALABS; [email-masked]; [email-masked]
Subject: RE: [NSIS] Alternatives for supporting domain-local admission controloperation in NSLP/QSPEC

Hi Roland, Georgios,

See below.

Thanks,
Regards,
Jerry

---

From: <[email-masked]>
Date: Mon, 27 Nov 2006 10:03:19 +0200

The QSPEC document is an Informational RFC, so your comment about this
is really not very relevant to the discussion.  
 
thanks,
John

	From: ext Roy, Radhika R. [mailto:[email-masked]] 
	Sent: 26 November, 2006 23:50
	To: Roland Bless; Georgios Karagiannis
	Cc: Loughney John (Nokia-NRC/Helsinki); Morton, Alfred C, JR
(Al), ALABS; [email-masked]; [email-masked]
	Subject: RE: [NSIS] Alternatives for supporting domain-local
admission controloperation in NSLP/QSPEC

	Ronald and Georgios:
	 
	Why is it too late to clean out the document as Ronald has
explained?
	 
	NSIS WG in particular and IETF in general have waited almost two
years to root out these "technically" inconsistencies. It is better NOT
to publish a standard track RFC like this.
	 
	If needed, NSIS WG Chair needs to appoint a "single" EDITOR who
can clean out this document.
	 
	Why does the NSIS WG Chair need to appoint 3 (Three) editors?
Is it not the problems of appointing 3 editors for the same simple RFC?
Is it not because of 3 editors who have put those things defying a
"simple" common sense that to keep the document is the most important
thing from the IETF point of view?
	 
	Is it not that people still trying to force so-called QOS SLAs
like Y.1541, DSTE, and 3GPP/Y.1541 in this draft as "standard" QOS
models?
	 
	A question to Georgios: Would you please provide any technical
justifications why so called "non-standard" QOS SLAs like Y.1541, DSTE,
and 3GPP/Y.1541 in this "standard" track RFC in the same level of IETF
"standard-based" RSVP, IntServ, and DiffServ QOS Model? Is it not mixing
between "apples" and "oranges?"
	 
	If Georgios cannot justify the above, references of so called
"non-standard" QOS SLAs like Y.1541, DSTE, and 3GPP/Y.1541 as even
examples for encoding of QSPEC parameters must NOT be included.
	 
	If it is done despite objections, we would think that this QSPEC
RFC must NOT be a "standard" track RFC because a standard track RFC must
NOT contain "non-standard" QOS models. This will also be brought to the
notice of the NSIS WG Chairs and IESG.
	 
	Best regards,
	Radhika

	From: [email-masked] on behalf of Ash, Gerald R (Jerry),
ALABS
	Sent: Sat 11/25/2006 7:44 AM
	To: Roland Bless; Georgios Karagiannis
	Cc: [email-masked]; Ash, Gerald R (Jerry), ALABS;
Morton, Alfred C, JR (Al), ALABS; [email-masked];
[email-masked]
	Subject: RE: [NSIS] Alternatives for supporting domain-local
admission controloperation in NSLP/QSPEC

	Hi Roland, Georgios,
	
	See below.

	
	Thanks,
	Regards,
	Jerry