[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



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:gash@att.com] 
>> Sent: 19 October 2002 00:17
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALASO; te-wg@ops.ietf.org
>> Subject: 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-routi
ng-04.txt
http://www.research.att.com/~jrex/jerry/

Thanks,
Jerry