Subject: RE: Reflecting new-MAM/SAM definition in diff-te drafts [[email-masked] in Pass-Through List] ['from' in Pass-Through List] [[email-masked] in Pass-Through List] ['from' in Pass-Through List]

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 20 May 2003 16:57:46 -0500

Francois, All,

> I've been using "Reserved" and "Normalised" as per their definitions in
> the proto draft, the RDM draft and the MAM draft.
> 
> Quoting from these drafts:
> 
> ==================================
> - "Reserved(CTc)": For a given Class-Type CTc ( 0 <= c <= MaxCT ) ,let
> us define "Reserved(CTc)" as the sum of the bandwidth reserved by all
> established LSPs which belong to CTc. 
> - Normalised(CTc) : let us define "Normalised(CTc)" as
> "Reserved(CTc)/LOM(c)", where LOM (c) is the Local Overbooking
> Multiplier for CTc defined in [DSTE-PROTO].
> =====================================
> 
> What that means is that "Reserved(CTc)" does factor in the overbooking
> method which is referred to as "LSP/link size overbooking" method and is
> the overbooking method commonly used in TE networks. However, it does
> NOT factor in the optional "Local Overbooking Multiplier" method.
> 
> "Normalised(CTc)"  factors-in both the "LSP/link size overbooking" and
> the optional "Local Overbooking Multiplier" method.

Thank you for reviewing this.  

I had not appreciated that 'Reserved(CTc)' is actually a normalized quantity, normalized by the 'LSP/link size overbooking multiplier' (LSOM).

Just to further clarify, in terms of the actual bandwidth requested, I suppose this relationship must hold:

Reserved(CTc) = Bandwidth-Requested(CTc)/LSOM

where

Bandwidth-Requested(CTc): For a given Class-Type CTc ( 0 <= c <= MaxCT ), define "Bandwidth-Requested(CTc)" as the sum of the bandwidth requested by all established LSPs which belong to CTc. 

Is that correct?  If so, then 'Reserved(CTc)' is also a 'normalized' quantity, but this time it is normalized by the LSOM, right?

Thanks for the clarifications,
Jerry

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 20 May 2003 16:57:46 -0500

Francois, All,

where

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 21 May 2003 10:04:36 +0100

Hello Jerry,

>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>> Sent: 20 May 2003 23:58
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; Lai, 
>> Wai S (Waisum), ALABS; Dimitry Haskin
>> Subject: RE: Reflecting new-MAM/SAM definition in diff-te drafts
>> 
>> 
>> Francois, All,
>> 
>> I had not appreciated that 'Reserved(CTc)' is actually a 
>> normalized quantity, normalized by the 'LSP/link size 
>> overbooking multiplier' (LSOM).
>> 
>> Just to further clarify, in terms of the actual bandwidth 
>> requested, I suppose this relationship must hold:
>> 
>> Bandwidth-Requested(CTc): For a given Class-Type CTc ( 0 <= 
>> c <= MaxCT ), define "Bandwidth-Requested(CTc)" as the sum 
>> of the bandwidth requested by all established LSPs which 
>> belong to CTc. 
>> 
>> Is that correct?  If so, then 'Reserved(CTc)' is also a 
>> 'normalized' quantity, but this time it is normalized by the 
>> LSOM, right?
>>

Yes, I do agree with your statement that "Reserved(CTc)" is also
normalised in the sense that it reflects the LSP/link size overbooking.

This is analogous to what happens today with regular TE. The bandwidth
that is configured as the LSP size may reflect some over/underbooking
factor. Similarly the Max Reservable bandwidth may reflect some
over/underbooking ratio.
The good thing is that from TE's perspective, the only thing we have to
worry about are these "normalised" bandwidth (reflecting LSP/link size
Overbooking).
If an LSP bandwidth is configured/signaled as 100, it is irrelevant (for
TE) whether the SP expects a peak load of 200 on that LSP and applied an
LSP overbooking of 2, or whether the SP actually expects a peak load of
100 and applied no overbooking.
Similarly, the relevant constraint is the Max Reservable Bandwidth
(which can be configured smaller or larger than real link capacity). For
TE, what matters is that the Max Reservable Bw is set to, say, 1000. It
doesn't really matter whether the link is actually indeed of 1000 or
whether it is actually a link of 500 with an link overbooking of 2.
Basically, TE will establish 10 LSPs of configured bandwidth 100 on that
link of 1000. That's it.
This is why, in regular TE, only the LSP bandwidth is the one considered
(and is indeed a normalised bandwidth factoring LSP Size Overbooking)
and only Max Reservable is considered (which is also a normalised value
factoring in the link size overbooking). 
One interesting point is that TE does not explicitely need the concept
of LSP size Overbooking *Multiplier" and the Link Size Overbooking
*Multiplier". They are effectively transparent to TE which works only on
normalised bandwidth. 

The DS-TE approach is the same with respect to LSP/link Size Overbooking
ie the only "bandwidth" we are concerned about is the actual LSP size,
which factors in the LSP Size Overbooking (ie which is normalised , as
you stated) and the BCs [+ Max Reservable Bw (as proposed)].
For DS-TE, like for TE, I think we don't need to explicitely define in
the drafts the concepts of LSP/Link Size overbooking Multipliers (LSOMs)
nor formulas using them because we operate directly/exclusively on
"normalised" values. But I think we  agree in spirit in what those would
be anyway, based on our discussion.

Thanks

Francois

PS: of course, as mentioned earlier, "Reserved(CTc)" factors LSOMs but
does not factor the LOMs. "Normalised(CTc)" does factor both.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 21 May 2003 10:04:36 +0100

Hello Jerry,

Thanks

Francois

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 21 May 2003 08:23:51 -0500

Hi Francois,

>> I suppose this relationship must hold:
>>
>> LSOM: 'LSP/link size overbooking multiplier'
>>
 
> One interesting point is that TE does not explicitly need the concept
> For DS-TE, like for TE, I think we don't need to explicitly define in

Thank you for the good and clear explanation.

Then, to clarify further, the following relationship would seem to hold:

LSOM = Max Reservable Bandwidth/Max Link Bandwidth

Is that correct?

If so, then another way to write your proposed formula for the sum of reserved bandwidth would be:

  o SUM (Normalized(CTc)) <= Max Link Bandwidth X LSOM
      for all "c" in the range 0 <= c <= (MaxCT-1)

Is that right?

Thanks,
Jerry

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 21 May 2003 08:23:51 -0500

Hi Francois,

Is that correct?

Is that right?

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 21 May 2003 14:47:55 +0100

Jerry,

See very far below: 

>> Sent: 21 May 2003 15:24

In the "LSP/Link Size Overbooking" method one can apply overbooking by
tweaking the LSP size (lets' call this the "LSP Size Overbooking")
and/or by tweaking the Max Reservable Bw (lets' call this the "Link Size
Overbooking").

Assuming we define LSOM as the "Link Size Overbooking Multiplier" (as
opposed to the "LSP/Link Size Overbooking Multiplier"), then I agree
with the above relationship.

Just to be clear, what I am trying to say is that the above relationship
you stated relates to the overbooking applied on the Link (but that the
overbooking applied on the LSP size is transparent to that because it is
already factored in the LSP size configured/signaled).

>>       for all "c" in the range 0 <= c <= (MaxCT-1)

Again, assuming we define LSOM as the "Link Size Overbooking Multiplier"
(as opposed to the "LSP/Link Size Overbooking Multiplier"), then I agree
with your relationship.

Thanks for helping get all this clarified.

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 21 May 2003 14:47:55 +0100

Jerry,

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 22 May 2003 15:27:56 +0100

Hello Sanjaya,

>> From: Choudhury, Sanjaya [mailto:[email-masked]] 
>> Sent: 22 May 2003 15:30
>> To: [email-masked]
>> Subject: RE: Reflecting new-MAM/SAM definition in diff-te 
>> drafts [[email-masked] in Pass-Through List] 
>> ['from' in Pass-Through List] [[email-masked] in 
>> Pass-Through List] ['from' in Pass-Through List]
>> 
>> 
>> > 
>> Hi! I am not sure it is necessary to introduce the concept 
>> of a new multiplier ("LSOM") in DSTE-PROTO. 
>>

Oh. I couldn't agree more. 

This is what I tried to indicate also in my earlier message:
[FLF] For DS-TE, like for TE, I think we don't need to explicitely 
[FLF] define in
[FLF] the drafts the concepts of LSP/Link Size overbooking 
[FLF] Multipliers (LSOMs)
[FLF] nor formulas using them because we operate directly/exclusively on
[FLF] "normalised" values.  

We only defined LSOM fo the purpose of the email discussion to
facilitate the discussions and confirmed we were all in synch in terms
of overbooking model. But I don't propose to add the LSOM
concept/formulas into the drafts.
 
>> Only change that should probably goto the draft is to replace
>> "Max Link Bw" in formulas by "Max reservable Bw", when user  
>> overrides the maxLinkBw (with a max reservable bw).
>> 

Right. "Max Reservable Bw" will be the value used as the aggregate
constraint on all CTs. 

>> Here is how I understand the types of overbookings:-
>> 1. Link size  overbooking
>> 	-user overrides the 'max link bw' (dictated by 
>> 	the hardware), with a larger/smaller bandwidth 
>> 	reservable on the link, be by configuring a 
>> 	'max reservable bw'.

Yes.
Minor detail. I am not sure what you meant exactly by "override". The
way I would put it is that we always use the Max Reservable bw (which
may be set by default to the actual Link Bandwidth or may be configured
by operator to some larger/smaller value). I think we agree.

>> 	-no additional multipliers are needed 

Yep.

>> 2. LSP size overbooking
>> 	-user reserves more/less amount of BW for the LSP
>> 	compared to the actual amount of traffic the LSP
>> 	is expected to carry.
>> 	-No additional 'multipliers' are needed. The LSP
>> 	BW follows the normal BCs based on the CTs

Yep.

>> 3. per CT overbooking
>> 	-user specifies the LOM on a per CT per interface
>> 	basis. LSP BW adheres to BCs dictated by the CT it
>> 	is associated with 

Yes. Factoring in the LOM, of course.

Good summary of overbooking methods. Thanks.

>> 	-when user has overridden the 'max link bw' by 
>> 	configuring a explicit 'max reservable bw', the 
>> 	user specified value should be used as the upper
>> 	limit for the link.
>> 
>> Reserved(CTx) vs Normalized(CTx):
>> If no LOM is being used, we can assume the LOM to be
>> 1 (100% no over/underbooking). This will allows us
>> to use Normalized(CTx) in all the formulas (instead
>> of two sets -one with Reserved and the other with 
>> Normalized).
>> 

The drafts already state that when LOM are not used it means they are
set to 1.
I had put the two sets of formulas with/without LOM because LOM is
purely an optional mechanism [ and frankly I don't expect it to be used
that often considering how much you can achieve with Link overbooking
and LSP overbooking] so I thought it would be useful to state the
formulas without LOM . 
Note that while the CAC formulas are pretty much the same with/without
LOM (with simple substitution of "reserved" by "normalised") the
formulas for computing Unreserved BW do get less intuitive with LOM than
without.

Thanks for your comments and analysis.

Francois

>> sanjay