[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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