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

From: Roland Bless <[email-masked]>
Date: Mon, 04 Dec 2006 11:17:09 +0100

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---------->QNR
              \               /           \               /
               +-------------+             +-------------+

> 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

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

---

From: <[email-masked]>
Date: Mon, 4 Dec 2006 15:04:56 +0200

Hi Roland,

>> complete description of the traffic source.  I believe we have 
>> consensus on that.
>

Agreed.

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

I agree, however, see below:

>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
>QNI--------->QNE--->QNE--->QNE---------->QNE--->QNE--->QNE--------->QN
>QNI--------->QNE--->QNE--->QNE---------->QNE--->QNE--->QNE--------->R
>             \               /           \               /

In the above example, I still worry what the relation is between the
e2e QSPEC, the RMD-QSPEC and the Y.1541-QSPEC.  I think we would need to
ensure that the RMD & Y.1541 QSPECs will sufficiently meet the e2e-QSPEC
needs, correct?  Do we have the protocol mechanism to ensure that, or
are we assuming the network deployments will take care of that?  I think
that we need text somewhere that talks about how the local QSPEC ensures
that the e2e QSPEC is met.

John

---

From: Roland Bless <[email-masked]>
Date: Mon, 04 Dec 2006 18:11:38 +0100

Hi John.

> e2e QSPEC, the RMD-QSPEC and the Y.1541-QSPEC.  I think we would need to

The RMD and Y.1541-QoSMs must define how they will map the e2e QSPEC
to their own model. But this must be done anyways, otherwise I don't
see how this will work at all.

> that the e2e QSPEC is met.

Yes, exactly. As already said in other mails:
Each QOSM should specify a mapping from the e2e QSPEC to its own
model, e.g. service classes. Therefore, if an internal QoSM specific
(or "local") QoSM is needed, one should also define what value goes into
the local parameters. However, a QOSM must understand the e2e QSPEC
and decide whether it can fulfill the request or not. It may change
the available QoS section in the e2e QSPEC accordingly. However,
the output must be an e2e QSPEC again. This can be easily achieved
by carrying the e2e QSPEC encapsulated in the local QSPEC.

The idea is that each QoSM only has to specify how the e2e QSPEC
is used for admission control (1:1 mapping) instead of having each QoSM
understand many others (n:1 mapping), which didn't worked out well as we
discussed in the last weeks (because you cannot compare apples and
oranges).

Regards,
 Roland

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 4 Dec 2006 11:37:40 -0600

Roland, John,

See below.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: Monday, December 04, 2006 12:12 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [NSIS] Support for local domain information in the QSPEC
> 
> Hi John.
> 

I'm concerned that we're straying from what I thought we agreed at
IETF-67.  There is no single generic e2e QSPEC, so it isn't possible IMO
for a QOSM to specify 'how the e2e QSPEC is used' as a general rule.

The rules for local QSPECs I thought we agreed on were these:

- edge nodes in local domains must interpret initiator QSPEC parameters
- edge nodes in local domains can either initiate parallel session with
local QSPEC or encapsulates a local QSPEC on initiator QSPEC
- local QSPEC interpreted by local domain QNEs
- local QSPEC must be consistent with initiator QSPEC (e.g. can re-set
TMOD with r=p, b/m to default)

Thanks,
Regards,
Jerry

---

From: Roland Bless <[email-masked]>
Date: Thu, 07 Dec 2006 11:47:15 +0100

Hi Jerry,

> for a QOSM to specify 'how the e2e QSPEC is used' as a general rule.

Maybe I can clarify that. What I denote as "e2e QSPEC" is
roughly "our" traffic source description + the constraints:
e2e QSPEC:={
Source traffic Description:
 TMOD-1 (mandatory to include)
 TMOD-2 (optional to include)

Constraints (optional to include):
 Path Latency
 Path Jitter
 Path PLR
 Path PER
 Priority (Preemption, Defending, Admission, RPH Priority)
}

I simply proposed to leave out any QoSM specific parameters
from the specification. So an e2e QSPEC will contain the TMOD-1
and one of the Constraints.

The idea is now that a domain - using a particular QOSM -
can take the e2e QSPEC and decide into which class the request
belongs and whether there are enough resources available there.
This is what I call mapping.
For example, within a DiffServ QOSM of one provider, the
particular constraints can be met by forwarding the flow in the
AF class, whereas another provider applying the same QOSM
may decide that this request belongs into another DS class,
e.g., because the network is engineered differently.
Mapping a T-MOD1 with Latency < 100ms may be easily mapped
to Y.1541 class 0 and then to a concrete DiffServ class.

> TMOD with r=p, b/m to default)

That's ok for me.
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 7 Dec 2006 13:18:07 +0100

Hi all

> > - edge nodes in local domains can either initiate parallel session 
> > with local QSPEC or encapsulates a local QSPEC on initiator QSPEC

This is okay for me too. 
Note that in the second case (local QSPEC must be consistent with initiator
QSPEC)
the local QSPEC can use a bandwidth parameter with a value equal to peak
(p).

Best regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Thu, 07 Dec 2006 14:06:30 +0100

Hi Georgios,

> the local QSPEC can use a bandwidth parameter with a value equal to peak

IMHO, the local QSPEC can use whatever "effective" bandwidth parameter
derived from the given e2e TMOD for admission control.
But since the local QSPEC remains local I don't really
care about that. The most important thing is that the initially
specified e2e QSPEC parameters (e.g. TMOD and QoS desired/MinQos)
are still the same when the e2e QSPEC leaves the domain again.

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 7 Dec 2006 14:08:26 +0100

Hi Roland

Okay, I agree!

Best Regards,
Georgios

> Sent: donderdag 7 december 2006 14:07
> To: Georgios Karagiannis
> Cc: 'Ash, Gerald R (Jerry), ALABS'; [email-masked]; 
> [email-masked]
> > the local QSPEC can use a bandwidth parameter with a value equal to 
> > peak (p).
> 
> IMHO, the local QSPEC can use whatever "effective" bandwidth 
> parameter derived from the given e2e TMOD for admission control.
> But since the local QSPEC remains local I don't really care 
> about that. The most important thing is that the initially 
> specified e2e QSPEC parameters (e.g. TMOD and QoS 
> desired/MinQos) are still the same when the e2e QSPEC leaves 
> the domain again.
> 
> Regards,
>  Roland
>

---

From: Bernd Schloer <[email-masked]>
Date: Thu, 7 Dec 2006 15:23:36 +0100 (MET)

Hi Roland,

is my understanding correct?

An e2e QSPEC must contain TMOD-1. TMOD-2 as well as _one_ of the Constraints is
optional. If an optional object is populated it must be interpreted by the QOSM.

Is the local QSPEC mandatory or can the e2e QSPEC be used within local domains?

Bernd

---

From: Roland Bless <[email-masked]>
Date: Thu, 07 Dec 2006 15:41:35 +0100

Hi Bernd,

Bernd Schloer wrote:
> An e2e QSPEC must contain TMOD-1. TMOD-2 as well as _one_ of the

can be more than one.

> Constraints is

I would say: TMOD-1 is necessary, one or more constraints are optional
but at least one constraint SHOULD be specified. Otherwise Best-effort
would be sufficient anyway, but for that you don't need any QoS
signaling at all.

> Is the local QSPEC mandatory or can the e2e QSPEC be used within local

No, you don't have to specify a local QSPEC. The e2e QSPEC should
be sufficient for most of the cases. You only need a local QSPEC if you
want to signal special or QOSM-specific parameters inside your domain.

Regards,
 Roland

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 7 Dec 2006 08:55:48 -0600

> > Is the local QSPEC mandatory or can the e2e QSPEC be used within
local
> > domains?

> want to signal special or QOSM-specific parameters inside your domain.

Furthermore, it should be possible to signal a 'QOSM-specific' parameter
in the initiator QSPEC.  E.g., a QNI may well want to signal Y.1541 QoS
class, which is intended to be an e2e parameter, in the 'e2e'/initiator
QSPEC.  No need for the QNI to put a local QSPEC on top of the initiator
('e2e') QSPEC in that case.

Thanks,
Jerry