RE: link capacity and reservable

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

>> -----Original Message-----
>> From: Lai, Wai S (Waisum), ALABS [mailto:[email protected]] 
>> Sent: 23 May 2003 20:58
>> To: [email protected]
>> Cc: Ash, Gerald R (Jerry), ALABS; Dimitry Haskin; Francois 
>> Le Faucheur (flefauch)
>> Subject: RE: link capacity and reservable
>> 
>> 
>> 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 assumed.  Once different overbooking factors are used
>> for different traffic 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 bw 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 protected]]
>> Sent: Tuesday, May 20, 2003 11:52 AM
>> To: Dimitry Haskin; Lai, Wai S (Waisum), ALABS; [email protected]
>> Cc: Ash, Gerald R (Jerry), ALABS
>> Subject: RE: link capacity and reservable
>> 
>> 
>> Dimitry,
>> 
>> >> -----Original Message-----
>> >> From: Dimitry Haskin [mailto:[email protected]] 
>> >> Sent: 20 May 2003 16:45
>> >> To: 'Lai, Wai S (Waisum), ALABS'; [email protected]
>> >> Cc: Dimitry Haskin; Francois Le Faucheur (flefauch); Ash, 
>> >> Gerald R (Jerry), ALABS
>> >> Subject: RE: link capacity and reservable
>> >> 
>> >> 
>> >> Waisum, Jerry,
>> >> 
>> >> IMO, both yours and Francois' formulas for the aggregate 
>> reservation
>> >> 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
>> >> 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.
>> >> 
>> 
>> Agreed.
>> 
>> Thanks
>> 
>> FRancois
>> 
>> >> Regards,
>> >>   Dimitry  
>> >> 
>> >> > -----Original Message-----
>> >> > From: Lai, Wai S (Waisum), ALABS [mailto:[email protected]]
>> >> > Sent: Monday, May 19, 2003 4:47 PM
>> >> > To: [email protected]
>> >> > Cc: Dimitry Haskin; Francois Le Faucheur (flefauch); 
>> Ash, Gerald R
>> >> > (Jerry), ALABS
>> >> > Subject: link capacity and reservable
>> >> > 
>> >> > 
>> >> > 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
>> >> > 
>> >> 
>>