RE: Progressing BC Models was RE: Progressing MAR

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

Jerry and all,

I don't have time to answer your detailed points below, so let me step
back and summarize how I look at the situation. I understand your
position, Jerry, and I understand you won't agree with some of what's
below, but I'd like to offer it as an input to the list for our
discussion in SFO, before I jump in the plane.

RDM was designed from discussions with a number of Service Providers
interested in DSTE. As discussed many times, RDM is a very attractive
trade-off as it is now. It works very well if preemption is used. It
actually also works reasonably well if preemption is not used : its main
drawback is that it cannot ensure isolation across Class-types, but it
achieves full efficiency and protection against QoS degradation. 
Where preemption is not to be used and isolation is the essential
criteria, MAM addresses these cases well (but at the expense of some
efficiency/QoS protection).
 
To address one of Jerry's concern about not finding implementations
which support a given model, I'd like to suggest that at the end of the
day it is Service Providers who will dictate which model is supported by
vendors. This is part of the rationale for not mandating any model. SPs
will just tell vendors which models need to be supported, and which
needs to be added later. This approach is precisely intended to keep
reactivity towards SPs requirements, not to hinder it. Again, the
analogy of Diff-Serv applies and vendors do implement the set of PHBs
requested by the market.

Both RDM and MAM specifications have been very stable for a while now.
There has not been any technical issues raised on the RDM specification
for two IETFs. Neither on MAM.

We have been working on DSTE for [what feels like 8^) an awfully ] long
time and it's more than time we came out with a base solution which is
implementable and deployable now. 

So let's close MAM and RDM asap so that in conjunction with the
diff-te-proto draft we have a solid (albeit not perfect) DSTE solution
to roll-out and get operational experience.

More investigations can be, and are being done to specify more
sophisticated models which may be able to work very well under all
possible situations and set of requirements. Extensions to RDM (to make
it work perfectly in all cases including without preemption as suggested
by Jerry) could be investigated in parralel, but they should not hold
off specifying RDM as it stands today.

Looking forward to discussing that in SFO.

Francois


>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] 
>> Sent: 14 March 2003 22:57
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALABS; te-wg@ops.ietf.org; Lai, 
>> Wai S (Waisum), ALABS
>> Subject: RE: Progressing BC Models was RE: Progressing MAR
>> 
>> 
>> Francois,
>> 
>> 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.
>> 
>> Jerry>> 
>> >> 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.
>> 
>> Francois> 
>> > Looking at the Atlanta minutes:
>> >
>> > "[Francois] Propose to document not only one model but 
>> rather to document
>> > two models. Propose that these two documented models be 
>> RDM and MAM. 
>> > ...
>> > Jerry recommended that the MA model be the default BC model and
>> > that the RD model be an optional BC model (should be used only
>> > when preemption is also used).  
>> > Jerry also recommended that we
>> > continue to study possible extensions to MA, such as MAR, to
>> > improve performance.
>> > ...
>> > [Waisum]: Draft is a comparison of MAM and RDM... Proposes 
>> to have MAM
>> > as default model."
>> > 
>> > So my reading of this is that at least back then, while we 
>> disagreed on
>> > which should be default vs optional, we actually all agreed on (i)
>> > specifying both MAM and RDM and (ii) further investigating MAR. My
>> > impression was that the group also agreed with this (or at the very
>> > least no one raised any issue with this).
>> 
>> These were the statements of 3 people in the Atlanta TEWG 
>> meeting, not a 'conclusion' of the WG.  As you very well 
>> know, the 3 of us agreed before the meeting to recommend 
>> that *both* MAM and RDM be default models.  The reason we 
>> agreed to that was that we could not accept RDM as the 
>> *single* default BC model.  This is because it performed 
>> poorly unless preemption is used, and many SPs don't use 
>> preemption (including AT&T).  If both MAM and RDM were 
>> required, we thought could be a compromise, then a SP could 
>> opt to use MAM, since it would be required to implement with DSTE.
>> 
>> However, the TEWG didn't agree to that recommendation (this 
>> is clear in the minutes).  Instead the issue went back to 
>> the list for discussion, and we've now agreed to your 
>> suggestion to have *no* default BC models.
>> 
>> Furthermore, given the agreement to have *no* required 
>> models, it makes it essential that all BC models meet all 
>> the BC model requirements.  SPs would not want to be put in 
>> the position where their vendors only implement RDM (and not 
>> MAM), which has unacceptable performance unless preemption 
>> is used.  Recall that under the present agreement, no BC 
>> models are required, it is a vendor's choice which to implement.  
>> 
>> Therefore RDM and all other BC models must meet the 
>> requirement to 'perform well with or without preemption', as 
>> well as all the other BC model requirements. 
>>  
>> > It sounds like one good objective for our SFO meeting would be to
>> > establish/document such agreement on :
>> > 	- which BC Model we should specify right away, and 
>> > 	- (coming back to Dimitry's question) which goes as
>> >       Standards/Experimental/Informational
>> 
>> Agreed.
>>  
>> > My proposal will be:
>> > 	- progress RDM right away in Standard Track
>> 
>> Disagree with that, until further extensions/protections are 
>> proposed for RDM to protect against poor performance when 
>> preemption is not used.
>> 
>> > 	- progress MAM right away in Standards Track
>> 
>> Agreed.
>> 
>> > 	- keep investigating MAM extensions like MAR, and based on
>> > upcoming conclusions decide then how to proceed
>> > (Standards/Experimental/Informational/no-specification).
>> 
>> We'll see where we're at in this discussion at the SF meeting.
>> 
>> >> 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.
>> 
>> > We have discussed the relative properties of RDM and MAM 
>> at length. This
>> > is precisely why we evolved towards specifying both RDM 
>> and MAM (rather
>> > than keep trying to come up with a single super model that works
>> > perfectly in all cases).
>> 
>> As above, I don't think we should specify/progress RDM in 
>> its current form.
>> 
>> > I am not suggesting everyone should use RDM; this is why 
>> MAM is also
>> > progressed.
>> 
>> The problem is that MAM is not *required*, so SPs cannot 
>> count on it being available from every vendor.
>>  
>> > Incidentally, perhaps mechanisms like
>> > draft-meyer-mpls-soft-preemption-00.txt may also alleviate 
>> some of the
>> > concerns associated with preemption.
>> 
>> If you mean that SPs who don't use preemption will suddenly 
>> opt to use soft preemption, certainly not.  Also, if one 
>> does too much soft preemption, and forces a lot of flows off 
>> of short routes onto much longer, inefficient routes, this 
>> would (perhaps severely) degrade network performance.  There 
>> are studies which show that effect.  One of the applications 
>> of bandwidth reservation mechanisms (as in MAR), used in 
>> large-scale networks today, is to protect against such an effect.
>> 
>> Thanks,
>> Jerry
>>