[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Progressing MAR
Jerry,
The bottom line is that MAR only achieves the stated objectives IF AND
ONLY IF a number of asumptions are made about the CT load distribution.
We have to be upfront about it rather than pretend it always work well.
The example provided earlier is a case where MAR simply can NOT provide
any isolation across CTs.
Then, we can debate more constructively on whether the CT load
distributions which break MAR are realistic for the packet networks
which are targetted by DS-TE.
It is far from obvious to me that they are not.
For example, a Service Provider using DS-TE in his network may only have
DS-TE tunnels for data initially and may only start building voice DS-TE
tunnels in a second stage as the VoIP load gets to a significant level.
This may result in many CTO/CT1 tunnels being setup first while CT2
tunnels only get established after. In that scenario, and assuming high
load, MAR would just NOT provide isolation across CTs (unless preemption
is used) and voice would just not get its share. Just an example. There
are other scenarios where a CT may grab more bandwidth than its share
and then not release it freely.
We should also use the same set of assumptions when assessing properties
of other models (not just for MAR).
For MAR to work well you basically need to make some assumption that one
CT will never have the opportunity to hog significantly more bandwidth
than its share and not release it later. If you make that sort of
assumptions, then you may find that RDM also works well without
preemption.
By definition preemption is only required with RDM (or probably any
model) if you make the opposite assumption that some CT will indeed hogg
bandwidth and never release it.
Also, it would be useful if you could provide some more information on
what sort of network you are refering as a refernce for MAR (is it
multiservice, what is the granularity of a routed element for voice: a
voice call, aggregate of calls from region to region, what is the
granularity for data,...). This is to relate it to packet environments
where DS-TE is intended.
In your draft, I only saw performance comparison between MAR and full
sharing across classes (which is the same thing as saying that you have
disabled DS-TE). So this seems to be illustrating that DS-TEwMAR is
better than no DS-TE at all. Which I guess we were kind of expecting.
It does not actually yet give indication on how MAR compares to other
models. Right?
Will you be adding comparison of DSTEwMAR to DSTEwMAM and to DS-TEwRDM?
Also for the performance analysis, it would again be useful if you could
clarify what you have taken as a "flow/LSP" for your simulation (ie what
sort of aggregate) to get an idea as to the analogy with DS-TE
environments.
Another useful element for the assement of MAR would be to indicate what
protocol extensions may be required to support it in distributed mode.
For example, I assume the IGP would have to advertise Bwalloc (which
could be advertised instead of the BCs) and would also have to advertise
RBW and BWIP for each CT. No?
Also, how do you signal in RSVP-TE the CAC priority you mention
(high/mid/low) for each CT: would you defined some extension to RSVP-TE
, or redefine the preemption pririty field?
This would help understand the impact on protocols when assessing MAR.
Thank you
Francois
>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
>> Sent: 16 March 2003 04:37
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALABS; te-wg@ops.ietf.org; Lai,
>> Wai S (Waisum), ALABS; Jim Boyle; Ed Kern (ejk)
>> Subject: RE: Progressing MAR
>>
>>
>> Francois,
>>
>> > What am I missing?
>>
>> We've been over such examples before. Let's not go over the
>> same ground again, please refer to the earlier
>> threads/responses for answers to your examples.
>> Basically,
>> as I've pointed out in the earlier threads, realistic
>> voice/data traffic patterns and network engineering rules
>> don't happen like that.
>>
>> All BC models should be designed to operate under actual
>> network conditions, traffic, and engineering. Let's focus
>> on realistic examples, with realistic traffic patterns and
>> engineering rules. For MAR, this is what is presented in
>> the I-D, real examples based on real traffic and engineering
>> design. I suggest you understand the examples in the I-D,
>> and point out where these are `incorrect`. That would be a
>> more worthwhile discussion I think.
>>
>> MAR is based on *operational* models in use for many years,
>> which of course must operate well under real traffic
>> conditions and which are engineered/designed in the way SP's
>> normally operate their networks. I think that's one thing
>> you're missing.
>>
>> Jerry
>>