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

["Lai, Wai S (Waisum), ALSVC" <wlai@att.com>]

  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:Shahram_Davari@pmc-sierra.com]
Sent: Tuesday, November 27, 2001 6:26 PM
To: Lai, Wai S (Waisum), ALSVC; te-wg@ops.ietf.org
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:Shahram_Davari@pmc-sierra.com] 
Sent: Tuesday, 27 November 2001 5:55 PM
To: 'Francois Le Faucheur'; te-wg@ops.ietf.org
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:flefauch@cisco.com]
> Sent: Tuesday, November 27, 2001 10:16 AM
> To: te-wg@ops.ietf.org
> 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