Subject: RE: [NSIS] Support for local domain information in the QSPEC

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 5 Dec 2006 10:54:40 -0500

Hi, John, Roland, and all:

Yes, we agree with Roland's proposal: Only one (generic) QSPEC object
e2e. Nothing else is needed in this "generic" draft.

Each QOSM draft will deal with its own local QSPEC object including
mapping between its own QOSM-specific local QSPEC and the "generic" QOS
object. Each QOSM needs to do a lot of things because they are "apples"
and "oranges." 

For example, so-called QOS-SLAs like Y.1541, DSTE, and 3GPP-Y.1541 will
have to do a lot of things, not limited to, as follows:

1. They have to find the proper signaling messages that need to be used
for NSIS-QOS signaling messages as they do not have their own.

2. They many even need to have some extensions in NSIS QOS signaling
messages here and there. Let them sort out those things.

3. They may need to see how their QOSM signaling messages can be used
with SIP call signaling messages for, say audio codec negotiations, as
they do not have any flexibility for negotiations other than some only
"one" fixed QOS-class that can be used for real-time services like
audio.

4. Item 3 clearly reveals the most important part of those QOS SLAs: a.
Bad Part and b. Good Part. 

4a. The bad part is this: The use of QOS signaling messages for "QOS
negotiations" of QOS-SLAs (Y.1541, DSTE, and 3GPP-Y.1541) is completely
UNECESSARY as there is NOTHING to negotiate because there is only fixed
value (one QOS Class) for QOS SLAs. If they want to create those
signaling messages, those will be wastage of resources for nothing
(i.e., at the end of all audio codec negotiations by SIP signaling
messages, there is only one QOS class).

4b. The good part is this: Like all SLAs, the Y.1541, DSTE, and
3GPP-Y.1541 QOS SLAs also want to AVOID unnecessary NEGOTIATION because
SLA has already been greed upon: Only one fixed value-based QOS class
for say real-time audio service. 

5. The question is this: How do the routers will implement item 4b? The
edge routers that implement the QOS SLA (say Y.1541) will just examine
the "general" QSPEC template and if the values of the QOS parameters
meet the bound of say Y.1541 QOS-SLA (e.g., delay < 50 msecs for audio
real-time services), it will accept the call. Otherwise, it will reject
the call.

6. The interesting question is this: How do the routers in item 5 know
which QOS class of say Y.1541 SLA? There are many solutions available
for this: i. Use OPS protocol that help to do so using VoIP call
signaling messages (SIP, H,323) mapping into IP layer, ii. Mark IP flows
agreed upon by ISPs as a part of SLA, iii. Manipulation of TOS agreed
upon by ISPs as a part of SLA, and iv. Many other schemes.

The key of the above explanations is this: If we use item 4a using some
extensions in the "generic" QSPEC draft (and even may require some other
NSIS QOS signaling messages as well) extending some signaling messages
as QOS-SLAs (Y.1541, DSTE, and 3GPP-Y.1541)do not have own signaling
messages, it is completely UNNECESSARY because their fundamental goal
has been item 4b.

If it is not true, why did these QOS-SLAs (Y.1541, DSTE, and
3GPP-Y.1541) create their own QOS signaling messages like RSVP,
DiffServ, and IntServ QOS Models?

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roland Bless
Sent: Monday, December 04, 2006 11:59 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [NSIS] Support for local domain information in the QSPEC

Hi John,

[email-masked] wrote:
> From your mail, Georgios's mail and Jerry's mail - I am not sure if we
> all have agreed or not on the role(s) of the QSPEC & the QoS NSLP.
> 
> If we have an e2e QSPEC and a local QSPEC, then I think the QoS NSLP
> will need to manage how to push & pop the local QSPEC, correct?

No. This is what can be solved by having only one QSPEC object conveyed
by the QoS NSLP: either it's a local (or QOSM specific) QSPEC or the
e2e QSPEC. One way to add local parameters is to define a local QSPEC
that encapsulates the e2e QSPEC and contains also parameters that are
relevant locally only. The QoSM defines how this is exactly done. What
must be ensured is that the QoSM understands the e2e QSPEC, i.e.
gets an e2e QSPEC as input, may create its local QSPEC (which
encapsulates the e2e QSPEC) and emits an e2e QSPEC at the egress to
the next domain again. By using this approach, each QOSM can define
what to do with the original e2e QSPEC (e.g. ignore in internal
routers etc.). There is also no need for push & pop.

> I think we would need to specify the following behaviors:
> 
> 1) e2e QSPEC vs. other QSPEC

I would allow both, though other QSPECs must maintain the semantics
of the e2e QSPEC (output must be e2e QSPEC at the egress).

> 2) How the QoS NSLP manages the interaction between these two

No, in my proposal the QOS NSLP doesn't deal with any QSPEC,
it simply delivers exactly one QSPEC object to the RMF and
gets exactly one QSPEC object from it (usually the local QSPEC
will encapsulate the e2e QSPEC to fulfill the above requirement)

> 3) How the e2e QSPEC and the 'other' QSPEC relate to each other,
>    which is manditory to support, which is optional, what to do
>    if the e2e QSPEC and the other QSPEC contradict each other.

Each QOSM that needs a local QSPEC should define a mapping
from the e2e QSPEC to its own local parameters, e.g. QoS classes.
The ingress node will create a local QSPEC (if needed at all)
and populate the QoS class parameter, adapt the available QoS
parameters in the e2e QSPEC and encapsulate it in the local QSPEC.
The egress node will terminate the local QSPEC and extract the
encapsulated e2e QSPEC for further forwarding then.

Regards,
 Roland

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 5 Dec 2006 13:33:37 -0500

Roland and all:

Roland is right. I am using Roland's following figure why it is
unnecessary for us to worry about Y.1541 QOS SLA.

                     RMD                        Y.1541
               +-------------+             +-------------+
    E2E-QSPEC /   RMD-QSPEC   \ E2E-QSPEC /  Y.1541-QSPEC \ E2E-QSPEC
QNI---------->QNE--->QNE--->QNE-------->[R1]-QNE--->QNE-->[R2]------>QNR
              \               /           \               /
               +-------------+             +-------------+

Please note that I have used two routers R1 and R2 in the network where
Y.1451 QOS-SLA has been implemented. Please also note that, like all
SLAs, Y.1451 QOS SLA is also non-negotiable as QOS classes are fixed per
application [e.g., voice = class 1 (delay <50ms); video, IM = class 2
(delay < 100ms); non-real-time data = class 3 (delay <500ms)].

All routers including R1 and R2 of SLA (Y.1451) know that they have to
implement Y.1451 SLA. So, they do not need to do anything to negotiate
so far QSPEC is concerned. That is, there is no need for Y.1451-QSPEC
template because the general E2E-QSPEC template is good enough. How?

Let me explain as follows:

1. E2E-QSPEC template will have the QOS parameters (delay, jitter, loss)
and the end system will specify their values. Once the values are known,
Y.1451-aware router R1 will just need to examine the values of those QOS
parameters. Examining those values of QOS parameters, R1 can decide
whether to accept or reject the call because it has nothing to
negotiate.

2. The thing that is needed for Y.1451-aware router R1 in item 1 is to
know which application has requested this. It is very interesting to map
between the application layer and the IP layer. In another email, I have
explained how fixed-value-based SLAs are implemented: OSP protocol
(SIP/H.323 <-> IP), IP TOS-bits, IP-flow-ID, and others. This mapping is
outside the scope of the NSIS WG unless Y.1451-SLA ISPs negotiate among
themselves which path they need to use. NSIS WG will assume somehow
there is a way to do so. Y.1451-QOSM is the right place that Y.1451-QOS
SLA folks will use all those schemes for implementations/mapping.

3. If Y.1451-QOS SLA folks want to create their own QSPEC templates and
want extend the generic QSPEC template, it will be messy. Not only this,
let us ask them one fundamental question: If they avoid to create QOS
signaling messages to avoid negotiations in the first place, why do they
NOW want to create extensions in QSPEC template signaling messages to
carry those "value specific non-negotiable" QOS class? Is it NOT a step
backward in the first place? How does it help them? Why do they not use
one of those "very simplistic" things as identified in item 2?

The bottom line is this:

Let the Y.1451-QOS SLA folks justify why do they want QOS signaling
messages in extending the "generic" QSPEC template for implementation
before doing any further works in this regard in Y.1451-QOSM draft?

Let the Y.1451-QOS SLA folks draw a simple call flow using the following
simplified figure as shown below justifying how Y.1451-QPSEC templates
are helpful instead of using the "generic" QSPEC template:

                   Y.1541
               +-------------+
    E2E-QSPEC /  Y.1541-QSPEC \ E2E-QSPEC
-------->[R1]-QNE--->QNE-->[R2]------>QNR
              \               /           
               +-------------+            

The Y.1451-QOS SLA folks are also being advised to use a SIP call flows
on the top of the network layer NSIS QOS signaling flows. Then they will
gain more insights why they do not need any QSPEC template of their own.

We think that the Y.1451-QOS SLA folks will create their lives miserable
if they use their own QSPEC template if they do NOT use one of the paths
as shown in items 1, 2, and 3.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roland Bless
Sent: Monday, December 04, 2006 5:17 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Support for local domain information in the QSPEC

Hi John and all,

[email-masked] wrote:
> I'm trying to tease through all of the mails on this, and so if my
> interpretation is incorrect, please suggest corrective text.

See below.

> At the previous IETF, Dave Oran proposed that we have a mathmatically
> complete description of the traffic source.  I believe we have
consensus
> on that.

Yes, no doubt. We need that.

> The open question is how to handle QoS model specific parameters:
> traffic class, diff serv classes, etc.
> 1) Include a common set of them as optional parameters in the QSPEC
> document and allow QoSM documents define additional parameters via an
> IANA registry. 

The problem that I see is that if a QoSM-specific parameter is attached
to the QSPEC, the next domain with a different QoSM cannot interpret
that parameter correctly ("apples and oranges"). Even if both domains
support DiffServ, they may have a totally different set of classes and
PHBs, so signaling the PHB may not be very useful (example: while the
QSPEC's constraints may be supported by some AF class in domain A,
domain B can only use one of it's EF classes for this. So signaling
an AF PHB from domain A to domain B doesn't make much sense IMHO).

More rationale on that is provided here:
http://www1.ietf.org/mail-archive/web/nsis/current/msg07206.html

> 2) Allow QoSM documents to define their own complete QSPECs, which are
> used within the QoSM domain, essentially defining an e2e QSPEC and a
> local QSPEC.

The e2e QSPEC should be defined as generic QSPEC in "the QSPEC
document". Local QSPECs should not define their own e2e QSPEC
rather than how the e2e QSPEC is mapped to their local QSPEC
parameters.
The local QSPEC will usually encapsulate this e2e QSPEC
in its own local QSPEC or have an exact 1:1 mapping so that the
e2e QSPEC is sent to the next domain.
See also
http://www1.ietf.org/mail-archive/web/nsis/current/msg07158.html
for further explanations. Maybe the following picture helps here:
                     RMD                        Y.1541
               +-------------+             +-------------+
    E2E-QSPEC /   RMD-QSPEC   \ E2E-QSPEC /  Y.1541-QSPEC \ E2E-QSPEC
QNI---------->QNE--->QNE--->QNE---------->QNE--->QNE--->QNE---------->QN
R
              \               /           \               /
               +-------------+             +-------------+

> I think Georgios summarized these quite well in:
> _http://www1.ietf.org/mail-archive/web/nsis/current/msg07164.html_
> 
> I believe that more people were favoring #2.  Of course, the devil is
> always in the details, as there have been discussions about what
> parameters belong where.

Regards,
 Roland