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

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 12 Nov 2002 16:38:12 -0000

Jerry,

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

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?

3) In the case where we want to provide all necessary information to a
Head-end to be able to perform optimisation in case of multiple LSP
establishment, what would be the parameters that would need to be
signaled in IGP (Bwalloc, RBW,...?)?

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

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Sat, 16 Nov 2002 19:00:06 -0500

Francois,

Responses to you further questions below.

Thanks,
Jerry

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2002 11:38 AM
> To: Ash, Gerald R (Jerry), ALASO
> Cc: [email-masked]
> Subject: FW: I-D ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt
> 
> one CT has had a chance to hog a lot of bandwidth. 

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.
 
> bandwidth apportionment via BWalloc[i] in case of contention, but does

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.
 
> Head-end to be able to perform optimization in case of multiple LSP
> signaled in IGP (BWalloc, RBW,...?)?

I think only available bandwidth (ILBW in the draft) needs to be signaled.

---

From: [email-masked]
Date: Sun, 17 Nov 2002 06:24:55 -0000

Jerry,

What assumptions (if any) are you making about a given
application/customer's ability to class-hop?  That is, potential to change
class types (maybe at will?) based on current/past QoS experience and
charging regime.

regards, Neil

> From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
> Sent: 17 November 2002 00:00
> To: Francois Le Faucheur (flefauch)
> Cc: Ash, Gerald R (Jerry), ALASO; te-wg
> Subject: RE: I-D
> ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt
> 
> 
> Francois,
> 
> > Subject: FW: I-D 
> ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt
> > 
> 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.
>  
> 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.
>

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Sun, 17 Nov 2002 11:15:18 -0500

Neil,
 
> class types (maybe at will?) based on current/past QoS experience and

Interesting question.  I don't think any of the default BC models being discussed (Russian Doll, Maximum Allocation, or Maximum Allocation with Reservation) make any assumption on class-hop.  More generally, I don't believe we have a requirement for class-hop capability in the default BC model.

Questions to list:

1. do we need a requirement for class-hop capability in the default BC model?
2. if so, what would be the necessary protocol mechanisms to make class-hop possible?

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 18 Nov 2002 13:04:55 -0000

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

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

Thanks

Francois

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Tue, 19 Nov 2002 23:30:22 -0500

Francois,

Please see responses below.

Thanks,
Jerry

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

> (which I believe is what we are targeting), then it seems to me that
> with MAR as described:
> 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

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.

> Model), then we have to combine it with some additional constraints (e.g.

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.

---

From: "Lu, Henry, NLNS" <[email-masked]>
Date: Wed, 20 Nov 2002 14:04:43 -0500

Jerry,

How are you. We are kind of slow here and I am reading a lot of your papers. I think I am lucky to meet you. 

There is one comments I like to make.

I am against that in MAR model, bandwidth allocation control should be depending on status of links. Congestion is a temporary state and it may come and goes depending on customers traffic. Since there are many ISPs may pump as much as traffic as they want, in order to take advantage of unused bandwidth in the network and pay less, we may see link congested. But I need to sell my bandwidth to other people based on our SLA with my customers. If I have CT1, as data service, of 5% and they pump near 100% of traffic and I need to add CT2, which is voice, I should have right to give the rest of bandwidth, say 95% to my new customer. As the result, CT1 can use only unused bandwidth assigned to CT2. Not the other way around. The link state of congestion should not be a factor prohibits me to assign my bandwidth to CT2.

I am not very clear on the dependency of what algorithm you are going to use for your bandwidth allocation control. I understand the part of estimated bandwidth needs, but I do not know on the dependency of "bandwidth in use" and "status of link". Can you help me on that? Thanks.

--Henry Lu 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALASO 
Sent: Saturday, November 16, 2002 4:00 PM
To: Francois Le Faucheur (flefauch)
Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]
Subject: RE: I-D

Francois,

Thanks,
Jerry

---

From: "Lu, Henry, NLNS" <[email-masked]>
Date: Wed, 20 Nov 2002 16:40:01 -0500

Jerry,

Let me get into some detail of my perspective.
Let's clarify some fundamentals of the variable we use in the algorithm.

I think CT should be semi-permanent, provisional quantity for each link LER needs to track on. This is assigned by service provider based on how the network should be running. Whether another CT can be added is depending on whether there is enough bandwidth available.

ABW, Available bandwidth should be another semi-permanent quantity LER needs to track on for each link. If requested DBW is smaller than ABW, the CT should be granted. 

RBW, Reserved bandwidth should be the total current reserved bandwidth for all CTs on that link. and ABW should be [(Link BW) - RBW]. This is also semi-permanent, as result of provisioning which needs to be tracked by LER.

BWalloc and BWmax, I have no problem on that. It is CT parameters. I do not know how these two number will convert to RBW for that CT. Is there a ratio to take 100% of BWalloc and 0% for BWmax? These two quantities is like SCR and PCR in ATM. The booking factor for SCR is 100% and PCR is depend on what application you are running and you need to estimate it based on your traffic pattern.

CT is like QoS in ATM, there are CBR, VBRrt, VBRnrt and UBR. Dynamic bandwidth allocation is functioning based on those assigned quantities.

As for whether LER should accept a connection using certain CT, in ATM, leaky bucket algorithm is used. In MPLS, MAR should come up with similar algorism. I think the fundamental difference between MPLS and ATM is RSVP. But RSVP should work within each CT and not go beyond that. All the BW we are talking about is on CT, not for the link. Then, we can start to work on the details. Please advice. Thanks.

--Henry Lu

-----Original Message-----
From: Lu, Henry, NLNS 
Sent: Wednesday, November 20, 2002 11:05 AM
To: Ash, Gerald R (Jerry), ALASO; Francois Le Faucheur (flefauch)
Cc: [email-masked]
Subject: RE: I-D

Jerry,

--Henry Lu 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALASO 
Sent: Saturday, November 16, 2002 4:00 PM
To: Francois Le Faucheur (flefauch)
Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]
Subject: RE: I-D

Francois,

Thanks,
Jerry