RE: Progressing BC Models was RE: Progressing MAR

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

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