Subject: link capacity and reservable

From: "Lai, Wai S (Waisum), ALABS" <[email-masked]>
Date: Mon, 19 May 2003 15:46:37 -0500

This is in response to the discussion of maximum reservable
bandwidth in
http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00264.html
http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00265.html
As the issue is not restricted solely to MAM, and has impact on
RDM and in fact all BC models, I am talking about it in a more
general context.

Current TE extension in IGP deals with aggregate traffic.
There is thus a simple average-overall relationship:
max link bandwidth = max reservable bandwidth/overbooking.
As a result, whether "max link bandwidth" is supported or
commonly used or not is immaterial.

In DS-TE, there is per-CT bandwidth contstraint and per-CT
overbooking.  Max reservable bandwidth should accordingly be
treated as a vector quantity.  Reflecting this view, the
following definition for MAM in <tewg-diff-te-reqts> is
adequate:
  for each value of b in the range 0 <= b <= 7:
    Reserved (CTb) <= BCb
(with some clarification in MAM spec regarding overbooking)

Also, the following additional condition for MAM definition as
proposed in the second message quoted above is both unneccsary
and incorrect:
  SUM (Reserved (CTc)) <= Max Reservable Bandwidth
    for all "c" in the range 0 <= c <= (MaxCT-1)

This is like when I have 15 dollars and 10 euros in my pocket,
then my max reserve is 25 (of what unit).

The "max link bandwidth," being a normalized quantity, is more
meaningful.  For admission control under MAM, in addition to
the observing the bandwidth constraints as specified in the
above deinition, something like the following may be used:
  SUM (Reserved (CTc)/overbooking(CTc)) <= Max Link Bandwidth
    for all "c" in the range 0 <= c <= (MaxCT-1)
(with some tweaks to account for priorities)

Thanks, Wai Sum

---

From: Dimitry Haskin <[email-masked]>
Date: Tue, 20 May 2003 10:44:46 -0400

Waisum, Jerry,

IMO, both yours and Francois' formulas for the aggregate reservation
constrain would achieve identical results. Note that max reservable b/w
constraint is simply applied to the sum of reservations at each CT which
already account for individual overbooking factors at each CT. However with
the formula that you are proposing we would completely shut the door for
other uses of the max link b/w TLV, for instance as a constraint on the max
LSP b/w. Since we have already a parameter that was explicitly defined as
the aggregate reservation constrain, there is no need to close door for a
different use of the max link b/w parameter at this point.

Regards,
  Dimitry  

> -----Original Message-----
> From: Lai, Wai S (Waisum), ALABS [mailto:[email-masked]]
> Sent: Monday, May 19, 2003 4:47 PM
> To: [email-masked]
> Cc: Dimitry Haskin; Francois Le Faucheur (flefauch); Ash, Gerald R
> (Jerry), ALABS
> Subject: link capacity and reservable
> 
>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 20 May 2003 16:51:38 +0100

Dimitry,

>> From: Dimitry Haskin [mailto:[email-masked]] 
>> Sent: 20 May 2003 16:45
>> To: 'Lai, Wai S (Waisum), ALABS'; [email-masked]
>> Cc: Dimitry Haskin; Francois Le Faucheur (flefauch); Ash, 
>> Gerald R (Jerry), ALABS
>> Subject: RE: link capacity and reservable
>> 
>> 
>> Waisum, Jerry,
>> 
>> constrain would achieve identical results. 

I guess you're right that at the end of the day it would be pretty much
the same thing functionnally.

>>Note that max 
>> reservable b/w

Agreed.

Thanks

FRancois

---

From: "Lai, Wai S (Waisum), ALABS" <[email-masked]>
Date: Sun, 25 May 2003 15:09:39 -0500

Jing,
  Many thanks for your example.
  As I stated earlier, current TE extension in IGP deals with
aggregate traffic.  Through a simple average-overall relationship:
max link bw = max reservable bw/overbooking,
it does not matter which quantity is used - in some sense they are
immutable under overbooking.
  But when different per-CT and per-link overbooking factors
are allowed, the use of "max reservable bw" in bw constraint
computation for admission control makes the rules more complex.
I think both your example and mine show that this is the case.
The use of some quantity that is normalized with respect to
the "max link bw" would be much more straightforward.
Thanks, Wai Sum

-----Original Message-----
From: Jing Shen [mailto:[email-masked]]
Sent: Sunday, May 25, 2003 3:58 AM
To: Lai, Wai S (Waisum), ALABS; [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS; Dimitry Haskin; Francois Le Faucheur (flefauch)
Subject: RE: link capacity and reservable

My question, if parameters in a new LSP setup request are converted as Lai stated, how could we select best path for new traffic flows?

for example, 
       /-----------b \
s----/                \--------t
    a \              /d
        \---------c/

S want to set up LSP of CT1  to T with bandwidth 5Mbps, while at node A there is tow branch ( to B or to C),  if link AC allow more overbooking than AB, but residual BW for CT1 is the same. 

Which path should we take ?  or should OSPF  use which value ( real BW or reservable BW) ? 

thanks 

Jing Shen

"Lai, Wai S (Waisum), ALABS" <[email-masked]> wrote:
Thanks to the responses from Jean-Louis, Dimitry, and Francois
regarding the issue on the use of max link bw versus max
reservable bw in my previous mesage (contained here at the end).

The main point underlying the issue that has so far not been
discussed is this, because of per-CT overbooking, max reservable
bw should be treated as a vector quantity (as in my previous
dollar/euro analogy). Let me illustrate by an example.

Max link bw = 100 (assuming some bw unit)
CT1: bw constraint = 80, LSP bw = 10
CT2: bw constraint = 70, LSP bw = 7

In this setting (with all the quantities above being normalized
with respect to link bw), we can accommodate under MAM any one
of these combinations:
8 CT1-LSPs + 2 CT2-LSPs = 94, 7 CT1-LSPs + 4 CT2-LSPs = 98,
6 CT1-LSPs + 5 CT2-LSPs = 95, 5 CT1-LSPs + 7 CT2-LSPs = 99,
4 CT1-LSPs + 8 CT2-LSPs = 96, 3 ! CT1-LSPs + 10 CT2-LSPs = 100.
The aggregate link bw's are all within the max link bw of 100.

Now consider the usage of reservable bw:
CT1: overbooking = 2, LSP reserved bw = 2 x 10 = 20
CT2: overbooking = 4, LSP reserved bw = 4 x 7 = 28

The corresponding max reservable bw's would be:
8 CT1-LSPs + 2 CT2-LSPs = 216
7 CT1-LSPs + 4 CT2-LSPs = 252
6 CT1-LSPs + 5 CT2-LSPs = 260
5 CT1-LSPs + 7 CT2-LSPs = 296
4 CT1-LSPs + 8 CT2-LSPs = 304
3 CT1-LSPs + 10 CT2-LSPs = 340

In contrast with max link bw, it's not clear what criterion
should be used to pick *a single value* from the above list
and use it as the "aggregate" max reservable bw. While MAM
is being used here for illustration, this problem is generic
and affects RDM as well.

As pointed out in my previous message, in current TE for
aggregate traffic, it is possible to define a single
"aggregate" max reservable bw value, since an average-overall
can be as! sumed. Once different overbooking factors are used
for different tr affic components (e.g., CT's), this is no longer
the case, and each traffic component has its own max reservable
bw. That's what I mean by treating max reservable bw as a vector
quantity with distinct components. This fact is actually also
independent of the type of overbooking methods used, i.e., LOM
or not LOM.

Thus, the proper way to do the computation is to first convert
reservable bw to link bw (or some equivalent normalized quantity),
and then check against the max link bw (or some equivalent
normalized quantity). Checking against the "aggregate" max
reservable bw is problematic since it is a list and not a single
value, as shown above.

Regarding the limit of bandwidth for a single LSP, that's already
taken care of by the per-CT bw constraint (since it is assumed
to be normalized). If folks want to use the max link bw for this
purpose, it's not precluded by the above consideration either
(because if the max link b! w puts a contraint on the aggregate
traffic, it certainly puts a contraint on a single LSP).

Thanks, Wai Sum

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: Tuesday, May 20, 2003 11:52 AM
To: Dimitry Haskin; Lai, Wai S (Waisum), ALABS; [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: link capacity and reservable

Dimitry,

>> constrain would achieve ide! ntical results. 

I guess you're right that at the end of the da y it would be pretty much
the same thing functionnally.

Agreed.

Thanks

FRancois

>> > From: Lai, Wai S (Waisum), A! LABS [mailto:[email-masked]]
>> > max link bandwidth = max reserva! ble bandwidth/overbooking.
>> > following definition for MAM in is
>> > adequate:
>&! gt; > This is like when I have 15 dollars and 10 euros in my pocket,

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 26 May 2003 13:09:32 +0100

Hello Waisum,

Thanks for your analysis.

The point you raise (aka is there a need for vectorisation of aggregate
constraints?) was actually one of the key technical points behind the
discussion we had at the time of breaking-out "Overbooking" into (i) LSP
Size Overbooking, (ii) Link Size Overbooking and (iii) per-CT Local
Overbooking Multiplier;

I believe there was clear agreement that:
	- there was a strong need for SPs to be able to apply, on a
network wide basis, a different level of overbooking for different CTs
(typically high overbooking on best-effort, low/no overbooking on
premium/voice)
	- this was well supported by the "Link Size Overbooking" method
(effectively just pretending to have a bigger link than the real one ;
and thus effectively applying a single per link overbooking which is
COMMON to all CTs)
	- there was a strong need for SPs to be able to apply a
different level of overbooking on differnet links (typically higher
overbooking on higher speed links)
	- this was well supported by the "LSP Size Overbooking" method
(which allows different overbooking per CT - it even offers finer
granularity of per-LSP overbooking) 
	- there was only a weak potential need for being able to apply
different overbooking ratios which need to be different for each CT on
different links.
	- this should be OPTIONAL
	- this would be well supported by the per-CT Local Overbooking
Multiplier.

A related conclusion of the above is that the "Link Size Overbooking"
method does NOT need to enforce different overbooking ratios for
different CTs. If the SP needs different overbooking ratios for
different CTs, then, in the context of DS-TE, this can be achieved via
the "LSP Size Overbooking" method.

Since the "Max Reservable Bandwidth" is involved only in the "LSP Size
Overbooking" method, it does NOT need to enforce a different level of
overbooking for different CTs; enforcing the same one across all CTs is
all what's required. This means that, taking into account the specific
environment of DS-TE, the aggregate constraint does not need to be
vectorised (although I agree that in a completely generic world it would
have to).

Now, in the case where the SP wants to enforce different overbooking
ratios for different CTs on different links, then this needs to be
achieved via the LOMs (and not via the "Link Size Overbooking"). Then
the LOMs need to be applied individually to each CT which effectively
results in the vectorisation you described. This will be reflected in
the CAC formulas when updated to reflect the aggregate constraint (which
will be applied to the "Normalised Bw"). 

So to recap in a nutshell, I believe the generic "vectorisation" issue
you discussed:
	- does not apply to Link Size Overbooking in the particular case
of DS-TE (since Link Size Overbooking does not need to enforce different
overbooking ratios across CT) and thus we only need a single "Max Res
Bw" value
	- does apply to the Local Overbooking Multiplier method and
is/will be reflected by applying the "Normalised Bw" when applying the
aggregate constraint.

Thanks for helping getting to the bottom of this question.

Cheers

Francois

>> Sent: 23 May 2003 20:58
>> 4 CT1-LSPs + 8 CT2-LSPs = 96, 3 CT1-LSPs + 10 CT2-LSPs = 100.
>> can be assumed.  Once different overbooking factors are used
>> for different traffic components (e.g., CT's), this is no longer
>> (because if the max link bw puts a contraint on the aggregate

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 26 May 2003 13:31:59 +0100

Hello again,

Specifically, here are the proposed updated formulas for MAM:

MAM Definition when LOM is NOT used (ie LOM[i]=1)
=================================================
o	for each value of b in the range 0 <= b <= 7:
            		Reserved (CTb) <= BCb,
o	SUM (Reserved(CTc)) <= Max-Reservable-Bw,   
		where the SUM is across all values of c in the range 0
<= c <= 7

MAM Definition when LOM is used 
===============================
o	for each value of b in the range 0 <= b <= 7:
            		Normalised (CTb) <= BCb,
o	SUM (Normalised(CTc)) <= Max-Reservable-Bw,   
		where the SUM is across all values of c in the range 0
<= c <= 7

"Unreserved TE-Class [i]" when LOM is NOT used (ie LOM[i]=1)
============================================================
	MIN  [
	[ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p ,
	[ Max_Reservable_Bw - SUM ( Reserved(CTb,q) ) ] for q <= p and 0
<= b <= 7,
         ]
where:
TE-Class [i] <--> < CTc , preemption p>
in the configured TE-Class mapping.

"Unreserved TE-Class [i]" when LOM is used
==========================================
	LOM(c) x MIN  [
	[ BCc - SUM ( Normalised(CTb,q) ) ] for q <= p,
	[ Max_Reservable_Bw - SUM ( Normalised(CTb,q) ) ] for q <= p and
0 <= b <= 7,
          ]
where:
TE-Class [i] <--> < CTc , preemption p> 
in the configured TE-Class mapping.

Cheers

Francois

>> From: Francois Le Faucheur (flefauch) 
>> Sent: 26 May 2003 14:10
>> The point you raise (aka is there a need for vectorisation 
>> of aggregate constraints?) was actually one of the key 
>> technical points behind the discussion we had at the time of 
>> breaking-out "Overbooking" into (i) LSP Size Overbooking, 
>> (ii) Link Size Overbooking and (iii) per-CT Local 
>> Overbooking Multiplier;
>> 
>> 	- there was a strong need for SPs to be able to apply, 
>> on a network wide basis, a different level of overbooking 
>> for different CTs (typically high overbooking on 
>> best-effort, low/no overbooking on premium/voice)
>> 	- this was well supported by the "Link Size 
>> Overbooking" method (effectively just pretending to have a 
>> bigger link than the real one ; and thus effectively 
>> applying a single per link overbooking which is COMMON to all CTs)
>> different level of overbooking on differnet links (typically 
>> higher overbooking on higher speed links)
>> 	- this was well supported by the "LSP Size Overbooking" 
>> method (which allows different overbooking per CT - it even 
>> offers finer granularity of per-LSP overbooking) 
>> 	- there was only a weak potential need for being able 
>> to apply different overbooking ratios which need to be 
>> different for each CT on different links.
>> 	- this would be well supported by the per-CT Local 
>> Overbooking Multiplier.
>> 
>> A related conclusion of the above is that the "Link Size 
>> Overbooking" method does NOT need to enforce different 
>> overbooking ratios for different CTs. If the SP needs 
>> different overbooking ratios for different CTs, then, in the 
>> context of DS-TE, this can be achieved via the "LSP Size 
>> Overbooking" method.
>> 
>> Since the "Max Reservable Bandwidth" is involved only in the 
>> "LSP Size Overbooking" method, it does NOT need to enforce a 
>> different level of overbooking for different CTs; enforcing 
>> the same one across all CTs is all what's required. This 
>> means that, taking into account the specific environment of 
>> DS-TE, the aggregate constraint does not need to be 
>> vectorised (although I agree that in a completely generic 
>> world it would have to).
>> 
>> Now, in the case where the SP wants to enforce different 
>> overbooking ratios for different CTs on different links, 
>> then this needs to be achieved via the LOMs (and not via the 
>> "Link Size Overbooking"). Then the LOMs need to be applied 
>> individually to each CT which effectively results in the 
>> vectorisation you described. This will be reflected in the 
>> CAC formulas when updated to reflect the aggregate 
>> constraint (which will be applied to the "Normalised Bw"). 
>> 
>> So to recap in a nutshell, I believe the generic 
>> "vectorisation" issue you discussed:
>> 	- does not apply to Link Size Overbooking in the 
>> particular case of DS-TE (since Link Size Overbooking does 
>> not need to enforce different overbooking ratios across CT) 
>> and thus we only need a single "Max Res Bw" value
>> 	- does apply to the Local Overbooking Multiplier method 
>> and is/will be reflected by applying the "Normalised Bw" 
>> when applying the aggregate constraint.
>>

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Mon, 26 May 2003 15:49:08 -0500

Francois,

I must say that there seems to be an over-complexity of over-booking options in DS-TE.  What is making this discussion over-ly confusing for me is that I think your explanation reversed the use of 'Link Size Overbooking' and 'LSP Size Overbooking' a couple of times.  Please check below between the ** marks where I've substituted what I thought was the correct explanation and/or term.

Sorry to add confusion if this 'correction' is incorrect :-)

Also, your discussion implies that LSP Size Overbooking and Link Size Overbooking are used individually, but not together.  If so, why can't they (or shouldn't they) be used together?

Thanks,
Jerry

*	- this was well supported by the "LSP Size Overbooking" method
granularity of per-LSP overbooking)*
*	- this was well supported by the "Link Size Overbooking" method
COMMON to all CTs)*

Since the "Max Reservable Bandwidth" is involved only in the "*Link* Size

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 27 May 2003 09:40:39 +0100

Hello Jerry,

>> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>> Sent: 26 May 2003 22:49
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
>> I must say that there seems to be an over-complexity of 
>> over-booking options in DS-TE.  What is making this 
>> discussion over-ly confusing for me is that I think your 
>> explanation reversed the use of 'Link Size Overbooking' and 
>> 'LSP Size Overbooking' a couple of times.  Please check 
>> below between the ** marks where I've substituted what I 
>> thought was the correct explanation and/or term.
>> 

You are absolutely correct that I did swap "LSP"/"Link". How silly is
that ... right in the middle of a text attempting to clarify things...
Thanks a lot for correcting it. Hope this removes the "over-confusion".

>> Also, your discussion implies that LSP Size Overbooking and 
>> Link Size Overbooking are used individually, but not 
>> together.  If so, why can't they (or shouldn't they) be used 
>> together?
>> 

I absolutely agree that "LSP Size Overbooking" and "Link Size
Overbooking" can be used simultaneously (I like that sentence because
even if I swap "LSP"/"Link" it is still correct 8^)).
This allows to simultaneously enforce overbooking ratios on a
per-CT-basis (eg. CT0 is overbooked by factor 2, CT1 is not overbooked)
and overbooking ratios on a per-link-basis (ie link0 is overbooked by
factor 1.3 and link1 is overbooked by factor 1.1). 

My point below was about enforcing overbooking ratios on a
per-CT-and-per-link basis (ie CT0 is overbooked by factor 2 on link 0
and overbooked by factor 3 on link 1, while CT1 is not overbooked on
link0 nor on link1). This could NOT be achieved just by combination of
"LSP Size overbooking" and "Link Size Overbooking"; it could only be
achieved via the use of the LOM method. But, as being discussed, it is
not obvious that the nbeed for this justifies the extra complexity.

Thank you

Francois

>> "*Link* Size
>> world it would

---

From: Dimitry Haskin <[email-masked]>
Date: Tue, 27 May 2003 11:37:20 -0400

Francois,

> not obvious that the nbeed for this justifies the extra complexity.

For my sake.. Since b/w constrains are advertised and handled per CT per TE
link (i.e. there are separate BCn values on each visible link in a TE
domain), why is LOM necessary to achieve overbooking per  CT per link?  Or
is it that link0 and link1 in your example form a some kind link bundle, i.e
form a single TE link as far as OSPF/ISIS TE extensions are concerned?

Thanks,
 Dimitry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 28 May 2003 09:57:42 +0100

Hello Dimitry,

>> Sent: 27 May 2003 17:37
>> To: Francois Le Faucheur (flefauch); Ash, Gerald R (Jerry), ALABS
>> Cc: [email-masked]
>> domain), why is LOM necessary to achieve overbooking per  CT 
>> per link?  

LOM is necessary because the BC Models we are considering enforce one
(or more) shared/aggregate constraint(s).

If we had a trivial BC model of pure independent bandwidth constraints,
then yes, each CT could operate independently and do its own computation
of how much is taken from its own BC. And we would not need LOM.

But since we have shared aggregate constraints (aka Max Reservable Bw)
you need to somehow configure what is the individual overbooking ratio
that is to be considered on that link for that CT, for the purpose of
deducting bandwidth from the shared/aggregate constraint. This is the
vectorisation issue that Waisum raised. The "euro vs dollar" question as
Wai put it.

In other words, considering MAM (with new definition), imagine you
configure BC0=1000 (probably reflecting some high overbooking) and
BC1=100 (probably reflecting some low overbooking), and
Max-Reservable-Bw=300 (probably reflecting an average overbooking on an
aggregate basis). One would not know exactly how to apply the Max
Reservable Bandwidth differntly to CT0 LSPs and CT1 LSPs in order to
compute the. For example if you have established one CT0 LSP of 500 and
one CT1 LSP of 50, how much exactly is left available to CT0 and CT1?

With the LOM solution, you configure BC0=100, BC1=50 , Max Reservable
Bw=130, LOM(0)=10 and LOM(1)=2. Then you know exactly how to apply the
Max Reservable Bandw constraints (see formulas in dste drafts) and how
to compute the available bandwidth for each CT dependeing on how much
LSPs are established acros ALL other CTs.

I suggest looking at section 6.2 of diff-te-russian where the formulas
make clear the role of LOM in various computation.

One could probably come up with solutions which are slightly different
to LOM, but the LOM solution is very attractive because, again, it is a
pure increment to the other overbooking methods which exist in TE today.

Cheers

Francois

>>Or

---

From: Dimitry Haskin <[email-masked]>
Date: Wed, 28 May 2003 11:33:37 -0400

Francois,

Thanks for your clear explanation. What has escaped me before is that LOM is
useful only for those cases where both of the following must be true:

 1) CTs of the same link have different overbooking ratios.
 2) The amount of reservations in one CT must precisely effect reservable
bandwidths in other CTs of the same link.

If I am correct, then it is quite possible to support different overbooking
ratios per CT per link without LOM, provided that 2) is not required (or at
least not with the same level of precision that LOM can provide).

Thanks,
 Dimitry

> Sent: Wednesday, May 28, 2003 4:58 AM
> To: Dimitry Haskin; Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 28 May 2003 16:52:19 +0100

Dimitry,

>> bandwidths in other CTs of the same link.

Yes.
 
>> ratios per CT per link without LOM, provided that 2)
>> is not 
>> required 

I would agree with that statement.
But in general,  2) seems highly desirable (ie it would seem odd to have
BC models which enforce aggregate constraints without having the ability
to apply this constraint fairly acurately over the various CTs).

Cheers

Francois

>>(or at