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

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 14 Nov 2006 16:01:07 -0500

Inline [RRR].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ash, Gerald R (Jerry), ALABS
Sent: Tuesday, November 14, 2006 3:01 PM
To: Roland Bless
Cc: Ash, Gerald R (Jerry), ALABS; NSIS Group
Subject: RE: [NSIS] Alternatives for supporting domain-local admission
controloperation in NSLP/QSPEC

Hi Roland,
...

I don't see the advantage in having multiple documents specify these
QSPEC parameters.  
...

[RRR] Multiple QOSM documents are already there. Each QOSM has its
unique needs to be satisfied. This generic QSPEC MUST not be
overburdened with because value-based SLAs like Y.1451, DSTE, and
3GPP/Y.1451 are NON-interoperable among themselves. They are also
NON-interoperable with other QOS models (RSVP, IntServ, and DiffServ).

[RRR] Even one document is not enough for Y.1451 because it does not
have its own signaling messages. First, Y.1451 has to create its own
extensions in NSIS QOS signaling messages to transfer its own set of
tightly coupled value-specific SLA QOS parameters. It will then need to
show how Y.1451 parameters will be used on e2e basis for call flows and
QOS negotiations in its own SLA-specific domain (please note that Y.1451
and DiffServ domain are not the same or similar. They are apples and
oranges).

[RRR] Example call flows using SIP application (or even network layer
NSIS signaling messages) need to be shown for Y.1451 for making people
believe that Y.1451 QOS negotiations work on e2e basis. The key question
is this: What kinds of QOS signaling messages one needs in NSIS QOS
signaling messages for Y.1451? Will those signaling messages work for
Y.1451 with any applications like SIP for QOS negotiations? For example,
SIP may use many codec types in a given INVITE message and each codec
will have its own QOS requirements. How will QOS signaling messages for
Y.1541 be used during codec negotiations?

[RRR] The Y.1451 QOS signaling message call flows need to be shown in
the draft to test whether those QOS signaling messages are sufficient.
Unless the draft itself shows how Y.1451 works using the NSIS QOS
signaling messages, it is almost "useless" to PRESS the entire NSIS WG
and IETF as a whole by making a un-substantiated statement that Y.1451
will work if some extensions are used in QSPEC draft for Y.1451. The
"generic" QSPEC draft is not the right place to do so.

[RRR] By the way, it is NOT the case for RSVP, IntServ, and DiffServ. If
so, what is missing in Y.1451?

Thanks,
Regards,
Jerry
 
> If there is, however, consensus for keeping the QoS class parameters
> in the generic QSPEC as optional, I'd like to see something like a
> "scope" parameter flag like Jukka proposed.
> 
> > Hopefully we are now ready to revise the QSPEC document 
> > according to the
> > agreements summarized in the presentation at IETF-67
> > 
> >
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
> > (subject to the revisions of including option 2/encapsulated QSPEC).

> As expressed in the meeting and above, I agree with the
> presentation for the most part of it.
> 
> Regards,
>  Roland
> 

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 15 Nov 2006 09:06:35 -0500

Roland:

I fully agree with you as we are implementing DiffServ domains in the
worldwide network as you have mentioned. The implementation of each
DiffServ domain may differ although they use the same or similar DSCPs
and PHBs.

In addition, the allocation of bandwidth in each DiffServ domain is also
a matter of implementations. Some use static means with over
provisioning while others use dynamic bandwidth allocation using some
proprietary schemes on the top of the DiffServ domain.

You are also right in pointing out that there is also specific QSOM
draft for each QOS model. The QOSM is NOT a generic one.

You are right in clarifying the things that each QOS model will use the
"generic QSPEC" draft for "encoding," "Extensions in NSIS QOS signaling
messages if any," "specific guidelines how use constraints in
conjunction with Token Bucket," and many other specific things.

Why do people want to "mess" the same "generic QSPEC" standard track RFC
using some implementation-specific guidelines that are sure to be
"incomplete" for standard QOS models and some non-standard QOS SLAs?

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roland Bless
Sent: Wednesday, November 15, 2006 4:52 AM
To: Ash, Gerald R (Jerry), ALABS
Cc: NSIS Group
Subject: Re: [NSIS] Alternatives for supporting domain-local admission
controloperation in NSLP/QSPEC

Hi Jerry,

Ash, Gerald R (Jerry), ALABS wrote:
> You have a point regarding signaling PHB class across domains using
> inconsistent classes.  However IMO it should still be possible for a
QNI
> to signal a PHB class if called for by the QNI's QOSM, and in which
> end-to-end interoperability/consistency may be achieved.  

As far as I know from old DiffServ times, each domain is free to
use its own DSCPs and PHBs (i.e. it may even remap PHBs on each other).
Furthermore, the "service" usually doesn't only depend on the PHB,
but also on the PDB, i.e. PHBs + traffic conditioning mechanisms.
I guess that it makes quite a difference what traffic conditioning
a domain is using. So signaling a PHB-ID alone isn't very meaningful
between different DiffServ domains (unless they are a DS region under
the same administration/provider) IMHO. So if end-to-end is within
a single domain or consistent DS region this may work, but between
different ASes?

> In addition, the Y.1541 parameter can be regarded as a 'summary'
> constraint parameter encompassing the latency, jitter, PLR, and PER
> constraints (as stated in the summary slides at IETF-67).  These
> parameters are intended to be signaled end-to-end across multiple
> domains.

Hmm. so it's only an abbreviation for the generic QSPEC parameters?
I see it as a profile description how to set the generic QSPEC
parameter values for different QoS classes defined in Y.1541.
But why not simply use the generic QSPEC?
I'm not against having a separate Y1541-QSPEC.
If this is going to get wide support, great!

> Therefore the QNI needs to signal these end-to-end parameters in some
> cases.
> 
> It seems that the proposal is to introduce a QoS NSLP specific
'generic
> QOSM', and everybody must map to this new QOSM.  We have tried

Oh no, please, big misunderstanging here!
I'm NOT talking about a generic QoSM, I'm talking about
a generic _QSPEC_. This is a really significant difference. While the
generic QSPEC may be mapped to any QoSM, mapping between QoSMs is not
going to work. I believe that it is really essential to allow different
QoSMs to be used. However, we need a common understanding of what
service is required between domains and I see the generic QSPEC as
a viable means to express that. In my understanding a QOSM is a means
to provide services, e.g. as proposed in Appendix VI of Y.1541 (using
a mapping from Y.1541 classes to Y.1221/DiffServ PHBs). This must be
completed, however, by specifying resource admission control algorithms
and traffic conditioning mechanisms.

> oftentimes to standardize a 'generic QOSM' and have not succeeded.
OTOH
> we have for a long time specified these parameters in a single
document.
> I don't see the advantage in having multiple documents specify these

So we must check for consensus to leave Y.1541 in the generic QSPEC.

Regards,
 Roland

---

From: "Roy, Radhika R." <[email-masked]>
Date: Fri, 17 Nov 2006 13:01:21 -0500

Roland:
 
A side conclusion of your email is as follows:

1.	

	DiffServ's DSCPs and PHBs provide a overall "generic" frame work how
a DiffServ QOS domain needs to work.
2.	

	The actual implementations of a given set of DSCPs and PHBs may vary
how QOS services are defined because QOS services are defined in the end
systems, and no one standardize any " end users' services" per se. For
example, a group of ISPs may be the end-users of a DiffServ domain that may
be agreed among them using a SLA. They may implement some services in this
DiffServ domain SLA that include real-time services (e.g., conversational
audio/video),  near-real-time services (e.g., streaming audio/video), and
non-real-time data services (e.g., interactive data, file transfer). They
may choose a set of DSCP and PHB for each service. Please note that these
ISPs still have not defined any specific values of any QOS performance
parameters. It just tells what kind of DiffServ services (DSCP Type, PHB
Type) will be used, Accordingly queuing disciplines, priority, dropping, or
other services in DiffServ nodes (i.e., routers) will be used for real-time,
near-real-time, and non-real-time application services
flows/packets/messages. This may be enough for these ISPs to satisfy their
DiffServ-based SLA needs.
3.	

	Another group of ISPs may use the same as described in item 2 for
their DiffServ-based SLA, but they may go further. For example, they may
also define specific values of delay, jitter, and packet loss for each
service such as  real-time (e.g., Y.1451 QOS Class I), near-real-time (e.g.,
Y.1451 QOS Class II), and non-real-time (e.g., Y.1451 QOS Class III)
application service. This may be the most "inflexible" SLA implementation.
4.	

	There can be numerous examples how different SLAs can be implemented
based on the "generic" DSCPs and PHBs standards.

In fact, the "generic" DHCP and PHB-based DiffServ standard is one of the
"most successful" QOS standards that have even been created in the history
of QOS. It shows the "beauty" of human creativity for its "enormous
flexibility," "usefulness" and "scalability" to address the QOS problems for
a large-scale vast complex IP network.

Let us also learn the above lesson in creation of the "generic" QSPEC
standard-track RFC removing any value-based implementation-specific QOS SLAs
like Y.1451, DSTE, and 3GPP/Y1451.

Best regards,

Radhika

  _____  

From: [email-masked] on behalf of Roy, Radhika R.
Sent: Wed 11/15/2006 9:06 AM
To: Roland Bless; Ash, Gerald R (Jerry), ALABS
Cc: NSIS Group
Subject: RE: [NSIS] Alternatives for supporting domain-local admission
controloperation in NSLP/QSPEC

Roland:

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of
Roland Bless
Sent: Wednesday, November 15, 2006 4:52 AM
To: Ash, Gerald R (Jerry), ALABS
Cc: NSIS Group
Subject: Re: [NSIS] Alternatives for supporting domain-local admission
controloperation in NSLP/QSPEC

Hi Jerry,

QNI

'generic

OTOH
document.

Regards,
 Roland