[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
- To: "Ash, Gerald R (Jerry), ALASO" <gash@att.com>
- Subject: RE: I-D ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt
- From: "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>
- Date: Mon, 21 Oct 2002 14:38:20 +0100
- Cc: <te-wg@ops.ietf.org>
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