Subject: RE: [NSIS] Alternatives for supportingdomain-localadmissioncontro loperation in NSLP/QSPEC

From: "Roy, Radhika R." <[email-masked]>
Date: Sun, 26 Nov 2006 17:15:09 -0500

John:
 
You are right to say, "I have seen any strong consensus for keeping the
Y.1541 class in the QSPEC." 
 
I am adding the following as well:

*	

	The so-called Y.1541, DSTE, and 3GPP/Y.1541 are "NON-Standard" QOS
models. They are rather value-based implementation-specific QOS SLAs and
have no properties that belong to a QOS model.
*	

	Per IETF, Y.1541, and 3GPP/Y.1541  are "Non-Standards."
*	

	Per IETF, only RSVP, IntServ, and DiffServ are "standard" QOS
Models.
*	As explained by many, the mixing of QOS models (RSVP, IntServ, and
DiffServ) and QOS SLAs (Y.1541, DSTE, and 3GPP/Y.1541) in the same draft
means mixing between "apples" and "oranges."
*	If PHBs are included for sake of DiffServ, the QSPECT RFC must NOT
contain anything specific that relates to "non-standard" Y.1541, DSTE, and
3GPP/Y.1541 QOS SLAs.
*	Moreover, a standard track RFC (QSPEC RFC) cannot contain
"non-standard" QOS SLAs.

Best regards,
Radhika
 
  _____  

From: [email-masked] on behalf of Ash, Gerald R (Jerry), ALABS
Sent: Thu 11/23/2006 8:59 AM
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,

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

> -----Original Message-----
> From: [email-masked] [mailto:[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,
>
> >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)

> 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.

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

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

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

---

From: <[email-masked]>
Date: Mon, 27 Nov 2006 09:13:55 +0200

Hi Radhika,

I think we know your position on this issue.  I've filled you position
on this issue, so you do not have repeat your position on this.

thanks,
John

>From: ext Roy, Radhika R. [mailto:[email-masked]] 
>Sent: 27 November, 2006 00:15
>To: Loughney John (Nokia-NRC/Helsinki)
>Cc: Morton, Alfred C, JR (Al), ALABS; [email-masked]
>	The so-called Y.1541, DSTE, and 3GPP/Y.1541 are 
>"NON-Standard" QOS models. They are rather value-based 
>implementation-specific QOS SLAs and have no properties that 
>belong to a QOS model.
>*	
>
>	Per IETF, only RSVP, IntServ, and DiffServ are 
>"standard" QOS Models.
>DiffServ) and QOS SLAs (Y.1541, DSTE, and 3GPP/Y.1541) in the 
>same draft means mixing between "apples" and "oranges."
>Cc: Ash, Gerald R (Jerry), ALABS; Morton, Alfred C, JR (Al), 
>ALABS; [email-masked]
>> >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)
>
>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
>