Subject: RE: [NSIS] Alternatives forsupportingdomain-localadmissioncontrol operation in NSLP/QSPEC

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

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 you 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.
 
Also please see inline [RRR].
 
Best regards,
Radhika

  _____  

From: [email-masked] on behalf of Georgios Karagiannis
Sent: Fri 11/24/2006 4:31 AM
To: 'Ash, Gerald R (Jerry), ALABS'; [email-masked]
Cc: 'Morton, Alfred C,JR (Al), ALABS'; [email-masked]
Subject: RE: [NSIS] Alternatives
forsupportingdomain-localadmissioncontroloperation in NSLP/QSPEC

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

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]
<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,
>
> 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
<https://www1.ietf.org/mailman/listinfo/nsis> 

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