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

["Francois Le Faucheur (flefauch)" <flefauch@cisco.com>]

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). 

But CT2 has already hogged a lot of bandwidth, leaving very little left
for CT0 and CT1 (unless we use preemption of course, or just wait
patiently until CT2 doesn't need bandwidth any more).
Pushing my earlier example further:
	- there is nothing stopping one CT from grabbing 90, if if sets
up its LSP before other CTs. 
	- Another CT is then left with only the remaining 10, which let
say it grabs, 
	- the other CTs have nothing left

>> 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). 

If we don't make any assumption about the order in which LSPs get setup
(which I believe is what we are targetting), then it seems to me that
with MAR as described :
	- either you specify a small RBW (as in your initial example
with RBW) and then there is very little "isolation" (ie one class can
hogg most of the bandwidth and some may even be completely starved).
	- or you make RBW large and then there is little efficiency (ie
large amount of bandwidth can go unused). Eg if you set RBW to 50, then
CT1+CT2 will be limited to 50, even if there is no other CT contending
right now, resulting in 50 of bandwidth going unused.

My impression is that if we want to approach the claimed properties of
MAR of (i) reasonable efficiency (ii) isolation (iii) WITHOUT preemption
(which is why we are considering this model in addition to Russian Dolls
Model), then we have to combine it with some additional constraints (eg
per CT maximum as used in Maximum Allocation Model).


>> 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 

Quoting from the "DS-TE Requirements" document:
  "The fundamental requirement for DS-TE is to be able to enforce 
   different bandwidth constraints for different sets of Traffic 
   Trunks. "

With MAR, the only "hard" constraint for any CT is the same for all CTs
and is (link-RBW).

Scenario 1 and 3 of "DS-TE Requirements" provide example of why "hard"
per-CT limit are required.


>>(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.

Right now, I can't see how MAR could satisfy the objectives without
adding something like per-CT maximums.

Thanks

Francois

>>  
>> > 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.
>>