Subject: Progressing BC Models was RE: Progressing MAR

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 14 Mar 2003 13:48:46 -0000

Hello Jerry,

See embedded :

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

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 noone raised any issue with this).

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

My proposal will be:
	- progress RDM right away in Standard Track
	- progress MAM right away in Standards Track
	- keep investigating MAM extensions like MAR, and based on
upcoming conclusions decide then how to proceed
(Standards/Experimental/Informational/no-specification).

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

We have discussed the relative properties of RDM and MAM at length. This
is precisely why we evolved towards speciying both RDM and MAM (rather
than keep trying to come up with a single super model that works
perfectly in all cases).
Some SPs do find RDM trade-offs very attractive. I believe Raymond Zhang
from Infonet, for example, indicated so at the mike at some stage in
Atlanta (although it didn't make it in the minutes).
I am not suggesting everyone should use RDM; this is why MAM is also
progressed.

Incidently, perhaps mechanisms like
draft-meyer-mpls-soft-preemption-00.txt may also alleviate some of the
concerns associated with preemption.

Cheers

Francois

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 14 Mar 2003 17:34:10 -0500

Hi Jerry,

I'll just comment on the last aspect for now. See in line,

At 15:56 14/03/2003 -0600, Ash, Gerald R (Jerry), ALABS wrote:
>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>>
>Francois>
> > "[Francois] Propose to document not only one model but rather to document
> > two models. Propose that these two documented models be RDM and MAM.
> > ...
> > as default model."
> > 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.
>
>Agreed.
>Disagree with that, until further extensions/protections are proposed for 
>RDM to protect against poor performance when preemption is not used.
>
>Agreed.
>We'll see where we're at in this discussion at the SF meeting.
>
> > is precisely why we evolved towards specifying both RDM and MAM (rather
>As above, I don't think we should specify/progress RDM in its current form.
>
>The problem is that MAM is not *required*, so SPs cannot count on it being 
>available from every vendor.
>
> > Incidentally, perhaps mechanisms like
>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.

As I'm co-authoring the soft preemption draft, I'd like to make a comment 
here. The point Francois wanted to stress which I think is perfectly valid 
is that one of the very well known limitation of the current preemption 
scheme is its disruptive nature for preempted TE LSP: indeed, a preempted 
TE LSP is just torn down which results in traffic disruption, something 
undesirable. Hence we came up with a proposal to signal a pending 
preemption to the HE of a soft preempted TE LSP so that the HE could 
perform a TE reroute (with make before break); this results in a very 
temporary overbooking but allows to avoid traffic disruption. I think this 
scheme can definitely help alleviating some issues with preemption schemes 
used with RDM.

Thanks.

JP.

>Thanks,
>Jerry

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Fri, 14 Mar 2003 17:49:15 -0600

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

> I am not sure how soft preemption, referring to the recent draft, forces
> flows off short routes onto longer ones.  Are you referring to preemption
> itself, regardless of whether its hard or soft?

The draft says: 
"a new preemption pending flag helps more gracefully mitigate the re-route process of displaced LSPs."

It's the re-routing of preempted LSPs (onto longer paths) that I'm referring to.

Jerry

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 14 Mar 2003 19:21:26 -0500

Hi Jerry,

>It's the re-routing of preempted LSPs (onto longer paths) that I'm 

So you're referring to preemption regardless of whether it is a hard or 
soft preemption. Indeed preempted TE LSPs may be rerouted along longer path 
but how could it be different ? If a link cannot handle the total amount of 
requested bandwidth, some TE LSP (with higher priority) can get the 
bandwidth, other TE LSPs (having a lower priority) will follow a longer 
path. Soft preemption just ensures that soft preempted TE LSPs get a chance 
to be gracefully rerouted (make before break) without traffic disruption.

JP.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Sat, 15 Mar 2003 12:14:43 -0000

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:[email-masked]] 
>> Sent: 14 March 2003 22:57
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; Lai, 
>> Wai S (Waisum), ALABS
>> Subject: RE: Progressing BC Models was RE: Progressing MAR
>> 
>> 
>> Francois,
>> 
>> Francois>>> 
>> 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 
>> 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. 
>>  
>> Disagree with that, until further extensions/protections are 
>> proposed for RDM to protect against poor performance when 
>> preemption is not used.
>> 
>> The problem is that MAM is not *required*, so SPs cannot 
>> count on it being available from every vendor.
>>  
>> 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