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

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

Francois,

Please see responses below.

Thanks,
Jerry

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

I don't think this is a very realistic example.  First, you're ignoring the engineering of BWalloc according to needed bandwidth.  It would be rare for CT2 to need so much more than its BWalloc (its engineered/needed BW level).  But if it did, the expectation based on design is that CT2 would quickly release unneeded bandwidth toward its BWalloc, freeing up bandwidth for other CTs.
 
>> 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 targeting), 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" (i.e. one class can
> hog most of the bandwidth and some may even be completely starved).
> 	- or you make RBW large and then there is little efficiency (i.e.
> large amount of bandwidth can go unused). E.g. 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.

In doing BW allocation, the design of the BW limits and thresholds, for any of the models, must be based on BW needs of each CT.  That is, the engineering design of the BW allocation model by the user/service-provider must be based on some realistic traffic model to work properly.  You created an example where it appears that the BC model is poorly designed and used.  

I believe RD and MA models are susceptible to the same sorts of 'bad-design' type problems, e.g., by setting voice CT bandwidth allocation to 99% and loading the bw up to that point and holding, no other CTs would have access to any bandwidth.  It's possible, but why would anyone use the bc model in this way?  Do we need to protect from users setting unrealistic thresholds and causing the model to perform badly?  I think it's reasonable to assume the bw allocation method with any default BC model will be used intelligently by the nms, router, and/or user configuration.

> 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 (e.g.
> per CT maximum as used in Maximum Allocation Model).

I agree that additional constraints could be added, but I don't see the reason/need for a such a constraint, other than to protect the users from making bad implementations of the intended use of the model (such as the example you gave).  If we do need to protect against such unintended use, then we should consider this issue in all the models, not just MAR.