RE: I-D ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt

["Ash, Gerald R (Jerry), ALASO" <gash@att.com>]

Francois,

Responses to you further questions below.

Thanks,
Jerry

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
> Sent: Tuesday, November 12, 2002 11:38 AM
> To: Ash, Gerald R (Jerry), ALASO
> Cc: te-wg@ops.ietf.org
> Subject: FW: I-D ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt
> 
> A few more questions on the example below:
> 
> 1) as described below, it looks to me like MAR would cope well with
> "overload" situations in situations where all CTs are gradually
> increasing their load at the same time so they start "contending" before
> one CT has had a chance to hog a lot of bandwidth. 
> But it is not clear how to me MAR would cope with situations where one
> CT gets greedy before the other CTs get a chance to contend: for
> example, if we assume that CT0 only has reserved 5 and CT1 only has
> reserved 5, is there anything that would prevent CT2 from reserving up
> to 80?

It could in the example.  However, only CT1 and CT0 could then increase their bandwidth (not CT2).  As CT1 and CT0 increase, the available bandwidth goes below the reserved bandwidth threshold (RBW), so CT2 can no longer increase its bandwidth, only decrease.  Furthermore, as flows/LSPs leave CT2, freeing up available bandwidth, then CT1 and CT0 can further increase, but CT0 can still only decrease.  RBW is set such that all CTs have a high probability of getting their allocated bandwidth (BWalloc).  CTs can go above their BWalloc when their is available bandwidth, however the BW reservation mechanism prevents them from hogging and also retaining the bandwidth above their BWalloc.
 
> 2) as described below, MAR seemed to target some minimum per-CT
> bandwidth apportionment via BWalloc[i] in case of contention, but does
> not seem to be able to enforce a hard "per-CT" maximum reservation in
> the absence of contention. 
> For example, let's say SP wants to first establish all the Voice TE-LSPs
> and want to limit those to 40% of link capacity for some voice
> engineering reason (say the Premium Data LSPs and Best-Effort LSPs will
> be established after the Voice LSPs).
> Could you use MAR to ensure CT2 Voice LSPs would be limited to 40% even
> when they are established before any CT1 and CT0 LSPs?
> Or are you assuming that load across all CTs is normally increasing
> simultaneously?

No assumption is made that CTs increase or decrease simultaneously.  As discussed above and in the draft, no CT can get much above its BWalloc when there is contention.  If there is no contention, then I'm not sure why you need to limit CTs to a maximum bandwidth, why not let a CT use the available bandwidth if there is demand (as described above, it cannot hold the bandwidth if contention arises later)?  A maximum reservation per CT could be added to MAR, of course, but it makes the BC model more complicated and it's unclear to me why it's needed.
 
> 3) In the case where we want to provide all necessary information to a
> Head-end to be able to perform optimization in case of multiple LSP
> establishment, what would be the parameters that would need to be
> signaled in IGP (BWalloc, RBW,...?)?

I think only available bandwidth (ILBW in the draft) needs to be signaled.
 
> Thanks
> 
> Francois
> 
>> We have 3 CTs: CT0, CT1, CT2, all with 'normal' priority.
>> We have a particular link with capacity = 100. 
>> MAR allocates CT bandwidth for the normal traffic loads, and 
>> in this example the BWalloc values on the given link are as follows:
>> 
>> BWalloc for CT0 = BWalloc0 = 30
>> BWalloc for CT1 = BWalloc1 = 20
>> BWalloc for CT2 = BWalloc2 = 20
>>  
>> This leaves 100 - 70 = 30 units of spare bandwidth on the 
>> link under normal loading.  With MAR, any of the CTs is 
>> allowed to exceed its BWalloc as long a there is at least 
>> RBWk (reserved bandwidth on the link) units of spare 
>> bandwidth remaining.
>> 
>> Let's say RBW = 10.  So under overload, if 
>> 
>> CT0 has taken 50 units of bandwidth (bandwidth-in-progress 
>> for CT0 = BWIP0 = 50),
>> CT1 has taken 30 units of bandwidth (bandwidth-in-progress 
>> for CT1 = BWIP1 = 30),
>> CT2 has taken 10 units of bandwidth (bandwidth-in-progress 
>> for CT2 = BWIP2 = 10),
>> 
>> Therefore, for this loading,
>> Idle link bandwidth (ILBW) = 100 - 50 - 30 - 10 = 10
>> 
>> Let's say a flow arrives for CT0 needing 5 units of 
>> bandwidth (i.e., DBW = 5).  We need to decide based on Table 
>> 2 and Table 1 whether to admit this flow or not.
>> 
>> The link load state is determined from Table 2:
>> 
>> Since ILBW - RBW < DBW (i.e., 10 - 10 < 5), Table 2 says the 
>> link is in the RBW (reserved bandwidth) state.
>> 
>> The allowed load state is determined from Table 1 (the 
>> allowed load state is the minimum level of bandwidth that 
>> must be available on a link to admit the flow):
>> 
>> Since for CT0 (normal priority) BWalloc0 < BWIP0 (30 < 50), 
>> Table 2 says the allowed load state is ABW (available bandwidth).
>> 
>> Hence since the link has less bandwidth (RBW state) than the 
>> allowed load state level of bandwidth required to admit the 
>> flow (ABW), the flow is rejected/blocked.
>> 
>> Now let's say a flow arrives for CT2 needing 5 units of 
>> bandwidth (i.e., DBW = 5).  We need to decide based on Table 
>> 2 and Table 1 whether to admit this flow or not.
>> 
>> The link load state is determined from Table 2:
>> 
>> Since ILBW - RBW < DBW (i.e., 10 - 10 < 5), Table 2 says the 
>> link is in the RBW (reserved bandwidth) state.
>> 
>> The allowed load state is determined from Table 1 (the 
>> allowed load state is the minimum level of bandwidth that 
>> must be available on a link to admit the flow):
>> 
>> Since for CT2 (normal priority) BWIP2 < BWalloc2 (10 < 20), 
>> Table 2 says the allowed load state is RBW (reserved bandwidth).
>> 
>> Hence since the link has sufficient bandwidth (RBW state) 
>> compared to the allowed load state level of bandwidth 
>> required to admit the flow (also RBW), the flow is admitted.
>> 
>> Hence, in the above example, in the current state of the 
>> link and the current CT loading, CT0 and CT1 can no longer 
>> increase their bandwidth on the link, since they are above 
>> their BWalloc values and there is only RBW=10 units of spare 
>> bandwidth left on the link.  
>> 
>> But CT2 can take the additional bandwidth (up to 10 units) 
>> if the demand arrives, since it is below its BWalloc value.