RE: link capacity and reservable

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

>> -----Original Message-----
>> From: Francois Le Faucheur (flefauch) 
>> Sent: 26 May 2003 14:10
>> To: 'Lai, Wai S (Waisum), ALABS'; [email protected]
>> Cc: Ash, Gerald R (Jerry), ALABS; Dimitry Haskin; Francois 
>> Le Faucheur (flefauch)
>> Subject: 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
>> >> >> > 
>> >> >> 
>> >> 
>>