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

From: [email-masked]
Date: Fri, 18 Oct 2002 11:06:39 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Max Allocation with Reservation BW Constraint Model 
                          for MPLS/DiffServ TE
	Author(s)	: J. Ash
	Filename	: draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt
	Pages		: 0
	Date		: 2002-10-17
	
This document is intended to complement the DiffServ-aware MPLS TE 
(DSTE) requirements document by describing the implications of some of 
the criteria for selecting a default bandwidth constraint model. 
Properties of a candidate model called maximum allocation with 
reservation (MAR) are presented, and its performance analyzed, to 
provide guidance to the corresponding DSTE protocol extensions document 
for selection of the default model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Fri, 18 Oct 2002 18:16:39 -0400

Francois,

Thanks for your comments.  See some responses below.

Thanks,
Jerry

P.S. I'll be out of email contact starting tonight for the next week, so any further replies from me won't be until then.

> From I-D:
> "Under normal non-congested network 
> conditions, all CTs/services fully share all available bandwidth.  When 
> congestion occurs for a particular CTi, bandwidth reservation acts to 
> prohibit traffic from other CTs from seizing the allocated capacity for 
> CTi."
> 
> Very basic question:
> Leaving alone all parameters and actual decision algorithms, do I get it
> right that it works something like this:
> Let's say I have CT0, CT1, CT2. 
> Let's consider a particular link with capacity 100. Let's say in periods
> of complete contention I want CT0 to have access to 30, CT1 to 30 and
> CT2 to 40.
> Let's say we currently have some CT0 but little CT1 and CT2 : CT0=30,
> CT2=10, CT3=10 
> Then I think the whole idea is that CT0 would need to be allowed to grab
> more than 30. Right?
> So let's say CT0 actually takes 50. So we have CT0=50, CT2=10, CT3=10.
> And we're happy because we're smarter than MAM by allowing CT0 to exceed
> its max bandwidth and thus increasing efficiency.
> But what happens if CT2 and CT3 later want to get their 30 and 40? Do we
> use preemption?

No, MAR doesn't require the use of preemption.

To begin with, MAR does not allocate bandwidth in the way your example suggests.  In practice, MAR allocates CT bandwidth for the normal traffic loads, so in an engineered network it never winds up that the BWalloc values on a given link add to 100% of the link bandwidth.  

So to re-cast your example to illustrate this:

CT0-BWalloc = 30
CT1-BWalloc = 20
CT2-BWalloc = 20

These are based on the normal traffic loads.  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,
CT1 has taken 30 units of bandwidth,
CT2 has taken 10 units of bandwidth,

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.

RBW is set such that the probability that each CT can get at least its BWalloc is quite high.  

As also discussed in the I-D, if best effort traffic is present, it can always seize whatever spare bandwidth is available on the link at the moment (30 units average for this example), but is subject to being lost at the queues in favor of the higher priority traffic.

More details of MAR operation, and many more simulation results, are given at (see ANNEX 3 in particular): 
http://www.ietf.org/internet-drafts/draft-ietf-tewg-qos-routing-04.txt
http://www.research.att.com/~jrex/jerry/

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 21 Oct 2002 14:38:20 +0100

Jerry,

Thanks for your answer. I get a better idea. But I am am still
struggling to understand the two tables in the I-D. 
Can you (or someone else who understand MAR) help me out:
	- what's the relationship between "Link Load States" and
"Allowed Load State Threshols"? Is the idea that I first determine the
"Link Load State" (which is CTi independent) to tell me whether I can
consider a link at all or not. And then assuming I can consider the link
(ie it is not in BNA state? ) I use Table 1 to tell me what thresholds
to apply?
	- how do I read Table 1: is it "if I am in state of first colum
and in priority of first row, then here is the formula to apply"  OR is
it "if I am in priority of first row and the condition of forumla
applies, then I am in state of first column"???
	- I think a worked example (like you started below but showing
how the table 1 and 2 come into play) would be really helpful.
Thanks

Francois

>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]] 
>> Sent: 19 October 2002 00:17
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]
>> Subject: RE: I-D 
>> ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt
>> 
>> 
>> Francois,
>> 
>> P.S. I'll be out of email contact starting tonight for the 
>> next week, so any further replies from me won't be until then.
>> 
>> > From I-D:
>> To begin with, MAR does not allocate bandwidth in the way 
>> your example suggests.  In practice, MAR allocates CT 
>> bandwidth for the normal traffic loads, so in an engineered 
>> network it never winds up that the BWalloc values on a given 
>> link add to 100% of the link bandwidth.  
>> 
>> These are based on the normal traffic loads.  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.
>> 
>> 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.
>> 
>> As also discussed in the I-D, if best effort traffic is 
>> present, it can always seize whatever spare bandwidth is 
>> available on the link at the moment (30 units average for 
>> this example), but is subject to being lost at the queues in 
>> favor of the higher priority traffic.
>> 
>> More details of MAR operation, and many more simulation 
>> results, are given at (see ANNEX 3 in particular): 

Thanks,
Jerry

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Sun, 27 Oct 2002 19:28:22 -0500

Francois,

> Thanks for your answer. I get a better idea. But I am still
> "Allowed Load State Thresholds"? Is the idea that I first determine the
> (i.e. it is not in BNA state? ) I use Table 1 to tell me what thresholds
> to apply?
> 	- how do I read Table 1: is it "if I am in state of first column
> it "if I am in priority of first row and the condition of formula

As you suggested, below I've expanded the example to give some illustration of the use of Table 1 and Table 2 in http://www.ietf.org/internet-drafts/draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt.

I hope this helps.

Thanks,
Jerry

Further additions to the prior example:

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.

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.