RE: Progressing MAR

["Ash, Gerald R (Jerry), ALABS" <gash@att.com>]

Francois,

> I believe the conclusion of our long discussion on BC Model was that we
> agreed to specify RDM and MAM and to investigate further other models
> including MAR.

I don't see that conclusion written down anywhere.  In Atlanta, the WG debated 1 default  versus 2 default models, and no conclusion was reached.  As to what to specify in the way of BC models, that's the discussion we're having now on all 3 models, so no conclusion is yet reached.

Anyway, my views are as follows:

1. progress MAM.

2. hold off on progressing RDM until some major issues have been resolved:
a) further extensions/protections should be proposed to protect against poor performance when preemption is not used,
b) at a minimum, provide a warning that RDM may be 'hazardous to the health of your network if preemption not used',
c) provide pointers to and/or inclusion of performance analysis.

3. continue the discussion on MAR toward a consensus.

There are service providers who do not use preemption, and have major concerns with RDM and its dependence on preemption to work well, that it can perform poorly when preemption is not enabled.  Our preference would be to use models not dependent on preemption (MAM or MAR).  There was much support on the list that a BC model should not require preemption to work well.  I think you should take that into account in RDM, and provide extensions to protect against same.

> 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.  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