RE: Progressing MAR

["Francois Le Faucheur (flefauch)" <flefauch@cisco.com>]

Jerry,

>> > I don't believe there is an agreement (at this stage 
>> anyway) that the WG
>> > needs to produce a spec for MAR. So my view is that it would be
>> > premature to have a WG document for MAR.
>> 
>> That is what we are discussing, so it is premature to draw a 
>> conclusion before the discussion, based only on your 
>> opinion.  We should continue the discussion on MAR toward a 
>> consensus. 

I certainly agree with you we should continue the discussion on MAR,
which is what I was doing in the rest of the message.

But your initial message asked for feed-back about accepting your
document as a WG document:
"I would like to get a sense of the list for using this I-D as the basis
for the MAR specification and for accepting this as a WG document.  "

I am just saying that right now it seems premature to me to turn any MAR
document into a WG document.
I'm not saying we should never have a MAR WG document, and/or that your
document would not be a good base for that.

So, more accurately, I am saying:
- if your question was intended to mean ".. for accepting this as a WG
document in some future if/when the WG has made a decision to specify
MAR", then my personal answer is I don't know yet; I need to think more
about MAR since I may not fully understand it yet.
- if your question was intended to mean ".. for accepting this as a WG
document now or in SFO", then my personal answer is that it is
premature.

Thanks 

Francois


 As stated in the I-D: 
>> "MAR is an extension of MAM and like MAM assigns a maximum 
>> bandwidth allocation to each CT, but with bandwidth 
>> reservation mechanisms, allows CTs to exceed their bandwidth 
>> allocations under conditions of no congestion but revert to 
>> their allocated bandwidths when overload and congestion 
>> occurs.  Analysis shows that MAR meets all the objectives 
>> for BC models, and that it simultaneously achieves bandwidth 
>> efficiency, bandwidth isolation, and protection against QoS 
>> degradation without preemption."
>> These are good reasons to pursue MAR as an extension of MAM.
>> 
>> > When we discussed the previous version of your MAR spec, 
>> if I remember
>> > correctly I think we ended up concluding that your claim that "it
>> > simultaneously achieves bandwidth efficiency, bandwidth 
>> isolation, and
>> > protection against QoS degradation without preemption" is ONLY true
>> > under the assumptions that :
>> > 	(i) the bandwidth that will be actually reserved by each CT is
>> > known fairly accurately ahead of time for every link (i.e. 
>> you need to be
>> > sure that on every link a CT will not, or only very 
>> temporarily, exceed
>> > its BWalloc).
>> > 	(ii) you configure the BWalloc of each CT based on the expected
>> > (and accurate) demand.
>> > Is this not the case?
>> 
>> No, see comments below.
>> 
>> > Personally, I see these assumptions as a serious problem.  
>> Basically it
>> > seems to defeat the whole purpose of DSTE: With DSTE you want to
>> > configure some limits for each CT based on resources available and
>> > engineering rules and have traffic redistributed in accordance with
>> > that. Its seems with -00.txt MAR description, you need to do the
>> > opposite i.e. configure the BWalloc based on what the load 
>> will actually
>> > and you assume that every link is engineered according to 
>> the actual
>> > demand without redistribution of load (which makes you 
>> wonder why you
>> > need DSTE in the first place).
>> 
>> Most service providers (SPs) don't operate their networks in 
>> the way you suggest, that is, SPs don't put capacity out 
>> there and then decide how to allocate it to whatever traffic 
>> might show up.  To the contrary, SPs engineer their networks 
>> based on traffic projections to determine needed capacity, 
>> topology, routing, etc.  Accordingly, CT bandwidth 
>> allocations are estimated.  More sophisticated methods (in 
>> actual use) make on-line measurements of bandwidth usage as 
>> a basis for the bandwidth allocations.  
>> 
>> Once bandwidth is allocated, there is *no assumption* that 
>> this will actually represent, or be close to, the actual 
>> traffic that arrives.  Extremely large swings and surges in 
>> traffic occur, massive overloads occur, failures occur.  MAR 
>> is expected to operate well under these conditions (and does 
>> in actual operation, see below).  All the BC models in fact, 
>> should operate well under these same conditions.  There 
>> should be no presumption of 'accuracy' in bandwidth 
>> allocations, etc. in any model, or that the actual load is 
>> necessarily always close to what you are allocating on all links.
>> 
>> Perhaps some SPs do operate in the way you describe (I know 
>> of none, so it is certainly not typical or even 
>> representative), but not having any knowledge/estimate of 
>> how much traffic you're allocating to each CT makes no 
>> sense.  You should also take into account the extensive, 
>> large-scale network experience with MAR-like mechanisms in 
>> many SP networks.  See the references in the I-D for a 
>> discussion of how MAR has been used to allocate bandwidth to 
>> 'class-types' for hundreds of millions of flows per day, 
>> with superb network performance and reliability.  In those 
>> applications, radical shifts in traffic loads occur 
>> regularly, overloads, surges, failures, etc. occur.  There 
>> is nothing akin to 'fairly-slow-changing, well-understood 
>> evolution' as you have characterized.
>> 
>> > Has something changed between -00.txt and -01.txt with 
>> respect to the
>> > above assumptions?
>> > 
>> > As discussed last time, MAR seems to contain a very good idea of
>> > allowing CTs to borrow bandwidth but I think we need to 
>> somehow enhance
>> > MAR to avoid the above assumptions/constraints (unless 
>> you've already
>> > done that in -01).
>> 
>> Per the above comments, I don't see that you have identified 
>> a real issue or as yet proposed any extensions.  
>> 
>> Thanks,
>> Jerry
>>