Subject: RE: Issues in draft-ietf-tewg-diff-te-reqts-02.txt

From: Jim Boyle <[email-masked]>
Date: Tue, 4 Dec 2001 12:32:56 -0500 (EST)

In your many to many, yes, in Francois' previous solutions, it did end up
being CTxPreemption values in syntax, but they were "orthogonal", so you
still only had 8 preemption levels.

By removing the explicit syntax to of {CT,P} and going to {CT} where P is
not externally explicit, you have different syntax, but semantically you
can associate a CT to multiple priorities, and cross-CT entries can have
the same preemption level.  Semantically it would be the same as only
using 8 cells in the CTxPreemption matrix, you just lose some external
visibility.

My approach had this completely arbitrary, the new protocol draft is not
so arbitrary, and has a fixed bandwidth model.  I'm interested in
scenarios which don't work with the model (russian doll model) in the
proto document.

Jim

On Thu, 29 Nov 2001, Lai, Wai S (Waisum), ALSVC wrote:

>   Here is some more discussion on the relationship between preemption and
> CT.  This started out as a response to the two emails sent by Shahram Davari
> (see Attachment 1 and Attachment 2 below).  However, I want to discuss it in
> a general setting, to trace a little bit on its development, and to explain
> the rationale for the proposal for the one-to-one correspondence for
> preemption/CT ("Issue 5: Relationship between preemption and CT" in the list
> of issues for the DS-TE Requirement <draft-ietf-tewg-diff-te-reqts-02.txt>).
>   All comments are welcome.
> Thanks, Wai Sum.
>
> ----------------
>
>   Preemption and CT may be "orthogonal" or "independent" for protocol
> design.  From a service provider's operational perspective, they are
> actually closely coupled, as network performance will be affected by the way
> they are related.  Consider the relationship between preemption (P) and
> class type (CT) as a form of P -> CT mapping.  Then, there are four
> possibilities: many-to-many, many-to-one, one-to-many, and one-to-one.
>
> Many-to-many
> ------------
>   Each CT can have many preemption levels, and each preemption level can be
> associated with more than one CT.  This is the mapping originally specified
> in the old 01 version of the DS-TE Requirements
> <draft-ietf-tewg-diff-te-reqts-01.txt> (June 2001) and the old 00 version of
> Solution <draft-lefaucheur-diff-te-proto-00.txt> (July 2001).  It leads to a
> rigid matrix structure of 4 class types x 8 preemption levels = 32
> combinations, with both within-CT preemption and cross-CT preemption.  It
> also requires complex IGP extensions for advertisement.  The problem in this
> regard is discussed in <draft-ash-mpls-diffserv-te-alternative-02.txt> (July
> 2001).
>
> Many-to-one
> -----------
>   In this case, there can be several preemption levels assigned to a single
> CT.  But each preemption level is only used by a single CT.  This is the
> approach now adopted in the new 01 version of Solution
> <draft-lefaucheur-diff-te-proto-01.txt> (November 2001).  For example, a CT
> can have a high-priority OA and a normal-priority OA combined.  To offer
> service protection, e.g., to avoid starvation of the normal-priority OA when
> preemption is allowed, different bandwidth constraints need to be specified
> for different OAs in the CT.  My feeling is that this kind of defeats the
> original purpose of CT, which is to use a single bandwidth constraint per CT
> through aggregation to improve the scalability of IGP advertisement.  (Side
> note:  This is also the case described in the "Overview and Principles of
> TE" document.)
>
> One-to-many
> -----------
>   Here, more than one CT can occupy the same preemption level.  But each CT
> is only assigned one preemption level.  This case is not really necessary,
> as it can be achieved by the one-to-one case below.
>
> One-to-one
> ----------
>   Each preemption level is assigned to one CT, and vice-versa.  By using the
> proposal in <draft-boyle-tewg-ds-nop-00.txt>, i.e., by generalizing the
> semantics of "priority" in current protocol extensions for TE, I think this
> case can achieve much of what the other cases are intended to do.  For
> example, CTs can be combined to allow better bandwidth sharing (the intent
> of the many-to-one case) within a router, as a local implementation, without
> resorting to IGP advertisement.  For the one-to-many case, it's a matter of
> defining two different priorities to be the same preemption level.  Similar
> considerations apply in the case preemption is not used.
>   Note that, because of one-to-one correspondence, each combination of {P,
> CT} effectively becomes a distinct CT.  Since there are 8 preemption levels,
> there are 8 {P, CT} combinations.
>   By using one-to-one mapping, the combination {P, CT} allows a more natural
> correspondence with the services to be provided.  For example, {P=0, CT=EF}
> corresponds to {high priority, voice}, {P=1, CT=EF} corresponds to {normal
> priority, voice}, {P=2, CT=AF} corresponds to {high priority, data}, {P=3,
> CT=AF} corresponds to {normal priority, data}.  Depending on whether {P=0}
> and {P=2} are defined by a service provider as the same preemption level or
> not, {P=0, CT=EF} and {P=2, CT=AF} may or not have higher priority over each
> other.
>
> ATTACHEMENT 1
> =============
>
> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2001 6:26 PM
> To: Lai, Wai S (Waisum), ALSVC; [email-masked]
> Subject: RE: Issues in draft-ietf-tewg-diff-te-reqts-02.txt
>
> Hi,
>
>  -----------------------------------------------
> > In Section 3.4 it says:
> >
> > "In other words, DS-TE must offer eight(8) preemption
> > priority levels to be
> > used by an LSP, that are completely orthogonal to that any other LSP's
> > attributes (eg LSP's OA, LSP's Class Type, etc.)."
> >
> > The utility of the concept of preemption being orthogonal to CT is not
> > clear.  If each CT is assigned one preemption level only, it
> > appears that
> > such concept is no longer necessary.  A one-to-one mapping
> > between CT and
> > preemption level does not preclude the possibility that some
> > related CTs may
> > be grouped together, as discussed in Issue 3.  We propose
> > that the statement
> > of orthogonality be removed.
>
> Could you please point out to where, in this draft, it is stated that "each
> CT is assigned one preemption level only"? I think this is stated in the
> te-proto draft, which should actually follow the requirement draft not vice
> versa.
>
> Since the Orthogonality is not that clear to some people, I suggest changing
> it to "independence" as following:
>
> "In other words, DS-TE must offer eight(8) preemption priority levels
>  to be used by an LSP, that are completely independent to any
>  other  attributes of that LSP(eg LSP's OA, LSP's Class Type, etc.)"
>
> Yours,
> -Shahram
>
> ATTACHMENT 2
> ============
>
> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, 27 November 2001 5:55 PM
> To: 'Francois Le Faucheur'; [email-masked]
> Subject: RE: Closer to a 'unified' ds-te approach ?
>
> Hi Francois,
>
> I think it is clear that the preemption priority of an LSP is independent of
> the CT or CTs that it is carrying. And this fact is acknowledged at the
> beginning of this document (section  2.2.1), when it states that CT and
> preemption are orthogonal. But section 2.2.2 tries to tie them together
> using a configurable mapping. This is contrary to all the previous
> assumptions and I see no reason to do so. The draft states that:
>
> "Each preemption priority is only used by a single CT".
>
> Why should we have this restriction? I think an example might make it clear:
>
> Assume that customer A is a Fortune 500 company and wants that its voice and
> data be transmitted without interruption. He wants low delay/loss for voice,
> and low loss and medium delay for data. Assume customer B, however, has a
> tight budget and is willing to accept interruption and call drops, but due
> to the nature of voice he wants low delay/loss for his voice connection,
> however he is willing to accept long delay and may be loss in his data
> connection. In summary
>
> Customer A: Voice => CT1, Preepmtion 0
>             Data  => CT2, preemption 0
> Customer B: Voice => CT1, preemption 1
>             Data  => CT3, preemption 1
>
> As you can see preemption 0 could be used by both CT1 and CT2.
>
> Yours,
> -Shahram
>
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:[email-masked]]
> > Sent: Tuesday, November 27, 2001 10:16 AM
> > To: [email-masked]
> > Subject: RE: Closer to a 'unified' ds-te approach ?
> >
> > >PS: If it doesn't get announced today I will put it on a
> > public ftp server
> > >tommorow morning European time.
> >
> > While it is percolating its way to the official IETF server,
> > draft-lefaucheur-diff-te-proto-01.txt is available from
> > ftp-eng.cisco.com/ftp/flefauch
> >
> > Cheers
> >
> > Francois
>

---

From: "Lai, Wai S (Waisum), ALSVC" <[email-masked]>
Date: Mon, 10 Dec 2001 18:18:34 -0500

I apologize for my late response.  Our Outlook email server was locked up by the goner virus and I didn't receive this message until towards the end of last week.
My vector addition of $.02 and Euro .02 inline.
Thanks, Wai Sum.

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Thursday, December 06, 2001 11:22 AM
To: Jim Boyle
Cc: Lai, Wai S (Waisum), ALSVC; [email-masked]
Subject: Re: Issues in draft-ietf-tewg-diff-te-reqts-02.txt

Waisum, Jim, and all,

At 11:46 04/12/2001 -0500, Jim Boyle wrote:

>My $.02 inline.

My Euro .02 in line:

>regards,
>
>Jim
>
>
>On Tue, 27 Nov 2001, Lai, Wai S (Waisum), ALSVC wrote:
>
> > During the preparation of DS-TE Requirements
> > <draft-ietf-tewg-diff-te-reqts-02.txt>, some issues needed further
> > discussion and hence were not incorporated into the text.  To facilitate
> > more discussion, they are listed below.
> >
> > Please comment on the issues.  If there are no objections raised, we 
> suggest
> > that the changes be incorporated into the next update of the above I-D.
> >
> > Thanks, Wai Sum and Jerry.
> >
> > Issue 1: CT definition
> > ----------------------
> > In Section 3.2, Class-Type (CT) is defined as
> > "the set of Traffic Trunks which share the exact same Bandwidth Constraint,
> > or set of Bandwidth Constraints, on all links, for the purpose of 
> Constraint
> > Based Routing and Admission Control."
> >
> > The above definition is technically incorrect.  A given LSP instance 
> has the
> > same bandwidth "on all links," but a class type cannot have the same
> > constraints "on all links," as exemplified by Scenario 2.  A workable
> > definition is provided below.
>
>Diffserv is by definition hop by hop, but I see no need to limit CTs as
>such.  I think the existing text is fine.  A certain CT, in my view,
>consist of all the resources in a network available to the CT, and all
>of the LSPs that call upon those resources.

I agree with Jim that current text is fine.
In any case, the text should convey that the traffic trunks of a given CT 
share Bandwidth Constraints throughout the network. In case Waisum's 
concern is that the text above may be misleading by suggesting that the 
actual value of the constraint should be the same on every link, we can 
rephrase to:
"the set of Traffic Trunks which, on all links,  share the exact same 
Bandwidth Constraint,
or set of Bandwidth Constraints configured on that link for the purpose of 
Constraint Based Routing and Admission Control."

Does that work for you?

[Wai Sum's response]  There is certainly the concern about the issue of "on all links."  The bigger issue is that there is the need to distinguish between network and link-local views of bandwidth information.
(1) For the network view, which is globally unique, "class type" definition is used to specify *how* network resources are made available to a class of traffic with similar characteristics, e.g., in its priority/preemption treatment at the LSP level with respect to other classes.  This view is used for constraint-based routing.
(2) For the link-local view, "class type" definition is used to specify *the amount* of link bandwidth available, e.g., in its relation to diffserv forwarding treatment at the packet level, and also for link affinity.  It is also for IGP advertisement of common per-link bandwidth constraint for all LSP's in the same class type.  This local view is used for per-link admission control and link bandwidth allocation.

>  >
> > Class Type (CT): the set of Traffic Trunks crossing a link that is governed
> > by a specific set of bandwidth constraints and whose packets receive either
> > the same or closely related DiffServ forwarding treatment.  CT is used for
> > purposes of link bandwidth allocation, constraint based routing, and
> > admission control.
> >
> > Issue 2: Split EF
> > -----------------
> > Also in Section 3.2, another example can be added as follows:
> >
> > A network operator may split the EF traffic into two different sets of
> > traffic trunks, so that one set of traffic trunks is given higher priority
> > access to bandwidth than the other set, to satisfy some QoS objectives.  In
> > this case, two distinct CTs are defined: one for the EF traffic with high
> > priority, the other for EF traffic with normal priority.
> >
> > (This example of split-EF traffic was already discussed within the author
> > team and no objections were raised.)
>
>This falls into the category of "Does one CT correspond to one and only
>one OA", or stated another way "Are we interested in tying DSTE lock-step
>to Diffserv, or is it something more flexible"
>
>Several have expressed a desire to make it more general, along the lines
>of what CT is refered to in the principles draft.  I agree, and think the
>above scenario is a valid way that a carrier might want to have two TE
>"classes" which are tangible and distinct, but both of which are one OA.
>You are right that we need to generalize CTs.

I am fine with the idea of providing an additional example to illustrate 
the generality of the CT definition.
I do have one problem with the above text because I think the 2nd sentence 
is not the most natural way to solve the need described in the first sentence.
If SP wants to split EF into two sets for the purpose of giving each a 
different priority in how they access bandwidth, then I think the most 
natural way to do this is to use two different preemption levels in the 
same CT.

[Wai Sum's response]  Are you saying that they (the two EF traffic classes) always need to be combined in the same CT?  What's the reason for being so?

I would thus propose a slightly modified text:
"A network operator may split the EF traffic into two different sets of 
traffic trunks, so that each set of traffic trunks is subject to different 
constraints on the bandwidth it can access. In this case, two distinct CTs 
are defined: one for the EF traffic subject to the first (set of) bandwidth 
constraint(s), the other for the EF traffic subject to the second (set of) 
bandwidth constraint(s)."

[Wai Sum's response]  It appears that the concept of priority has not been captured in the above statement.

>  >
> > Issue 3: Max number of BW constraints
> > -------------------------------------
> > It is proposed to add the following requirement in Section 3.3.
> >
> > By definition of CT, each CT is assigned either a Bandwidth Constraint, 
> or a
> > set of Bandwidth Constraints.  Since there is a maximum of 8 CTs, there is
> > correspondingly a maximum of 8 sets of Bandwidth Constraints.  That is,
> > maxCT = maxBC = 8, for IGP advertisement purposes.
> >
> > There is the possibility that some related CTs may be grouped together and
> > share a common set of bandwidth constraints.  However, such kind of 
> grouping
> > can be handled and enforced purely inside a router without being advertised
> > by the IGP.  This is because the use of such information in the computation
> > of unreserved bandwidths is a local matter.
>
>I agree that we should try to limit the amount of bandwidth constraints
>that are advertised, though additional "internal" constraints might be in
>use within an LSR (for instance, grouping bandwidth usage of two CTs).

I am quite happy with the document limiting the maximum number of Bandwidth 
Constraints and 8 is a fine number.

But I find the text proposed above misleading in the sense that it seems to 
suggest that because there is only 8CTs there could only be 8 BCs which is 
absolutely untrue since we do not defined the set of bandwidth constraints 
applying to CTs. With an open BC model, one could define a BC model with 
one BC per CT plus an additional aggregate BC for all the CTs, that would 
mean 9 BCs.

[Wai Sum's response]  I am not sure what's meant by an "open" BC model.  If there is one BC specified for each CT and there are 8 CT's, then there are 8 BC's.  Given that these 8 BC's are all advertised, it is not clear why the aggregate BC (i.e., the 9th BC) cannot be derived from the separate per-CT bandwidth information, and why the aggregate information needs to be advertised.

My proposal would be to simply add at the end of section 3.3 something like:
"Regardless of the Bandwidth Constraint Model, the DS-TE solution must 
allow up to a maximum of 8 BCs."

>  >
> > Issue 4: Suppression of preemption
> > ----------------------------------
> > It is proposed to add the following requirement in Section 3.4.
> >
> > A service provider preferring not to use preemption for user traffic should
> > not be burdened by the overheads associated with preemption.  Thus, a
> > service provider should not need to set all class types to the same
> > preemption level to avoid using preemption.
>
>As in the rsvp draft and with some implementations, use of preemption
>should be optional.

I need to think more about this.

> >
> > Issue 5: Relationship between preemption and CT
> > "In other words, DS-TE must offer eight(8) preemption priority levels to be
> > clear.  If each CT is assigned one preemption level only, it appears that
> > such concept is no longer necessary.  A one-to-one mapping between CT and

Section 3.4 also says:
"  Thus, DS-TE must allow two different LSPs transporting Traffic
    Trunks of the same Class-Type to use different preemption
    priorities, and allow the LSP with higher priority to preempt the
    other one when they contend for resources."
so there is obviously not a one-to-one mapping .

[Wai Sum's response]  It is not clear why there is such a requirement from the service provider's perspective (i.e., its utility).  There is at least one class of solutions, i.e, the ones using one-to-one mapping, that does not need this requirement.  Other classes of solutions may need this requirement in order to work.  However, unless there is a service provider need for it, it is suggested that the above paragraph be removed.

> > preemption level does not preclude the possibility that some related 
> CTs may
> > be grouped together, as discussed in Issue 3.  We propose that the 
> statement

Arguably, there is some redundancy in 3.4. So I have no objection to 
removing the sentence containing the word "orthogonal" as long as the the 
2nd paragraph of 3.4 remains intact.

Cheers

Francois

>Maybe they are not so much orthoginal, as not necessarily unique?
>
>I do like limiting the amount of external information, and of course I
>like reusing the existing advertisement structure and codepoints.
>Decoupling the advertised values from the actual priority could be useful.