Subject: RE: IETF54- Informal discussion on BC Model for DS-TE

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 16 Jul 2002 08:03:17 +0900

Neil,

At 16:38 15/07/2002 +0100, [email-masked] wrote:
>Francois,
>
>Your comments seem OK to me.......but I have to point out that my
>observation on pre-emption was quite general (so not just this DS/TE case,
>and it can also apply to other network technologies like ATM or even SDH
>VCs).  I am not so concerned for cases where traffic that gets dropped stays
>dropped (which is similar to the 1:1/N protection switching case when 'extra
>traffic' which is using the protection path gets dropped when the 'working'
>traffic path fails), but rather where multiple priorities exist and one get
>get a knock-on effect of 'bumped' traffic subsequently 'bumping' lower
>priority traffic (and so on).

Thanks. Makes sense to me.

Let me reclarify that
         - the Russian Dolls model does not "mandate" preemption. It can 
certainly be used without preemption.
         - when used without preemption, it works reasonably well , but not 
perfectly. ie it achieves bandwidth efficiency and avoids QoS degradation. 
but it cannot provide complete isolation.

Now, the MAM model, can also work without preemption. When used without 
preemption, it can provide isolation, but this is at the cost of very large 
inefficiencies.

Where I am getting at is that while it MUST be possible to disable 
preemption and the model should still work reasonably well without 
preemption, there are other goals which are kind of pushing towards use of 
preemption . So, in the specific context of selection of a Default BC Model 
for DS-TE, we must keep it mind that the exercise is all about picking a 
good compromise (must work without preemption, but may have to involve 
preemption to achieve some particular combination of goals).

Unless, of course, we identify some new model which can do everything 
simultaneously, but this is not documented yet.

Cheers

Francois

>regards, Neil
>
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:[email-masked]]
> > Sent: 15 July 2002 15:22
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: IETF54- Informal discussion on BC Model for DS-TE
> >
> >
> > Neil and all,
> >
> > At 10:47 15/07/2002 +0100, [email-masked] wrote:
> > >I'd agree with this too......our experience of pre-emption
> > schemes in other
> > >technologies tells us we would want to be able to disable them.
> >
> > So we're hearing:
> >          -i- it should be possible to disable preemption
> >          -ii- when preemption is disabled, the Model should
> > still work
> > reasonably well.
> > Fair enough.
> >
> > I also understand that:
> >          -iii- there should be effective use of bandwidth (ie good
> > bandwidth sharing among CTs).
> >          -iv- there should be some isolation (ie a CT cannot
> > hogg the bw of
> > another CT).
> >          -v- there should be protection against QoS
> > degradation (at least
> > of the premium CTs e.g Voice, Premium DAta...).
> >          -vi- the BC model should be reasoanly simple and
> > shouldn't require
> > additional IGP extensions.
> > Is this right, or are any of those actually non-goals?
> >
> > Thanks
> >
> > Francois
> >
> >
> > >regards, Neil
> > >
> > > > -----Original Message-----
> > > > From: Geib, Ruediger [mailto:[email-masked]]
> > > > Sent: 15 July 2002 08:21
> > > > To: [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: RE: IETF54- Informal discussion on BC Model for DS-TE
> > > >
> > > >
> > > > Hi Jerry
> > > >
> > > > > > Russian Dolls model does not "mandate" the use of
> > > > > > preemption. It just uses it for what it has been specified
> > > > > > for (ie bounce off LSPs when needed).
> > > > > >
> > > > > > My impression is that it is just not possible to
> > simultanesouly :
> > > > > >          -(i) ensure bandwidth sharing (ie no
> > bandwidth wastage)
> > > > > >          -(ii) ensure bandwidth isolation (ie a CT cannot
> > > > > >               have some of its bandwidth taken by another CT)
> > > > > >          -(iii) refuse to use preemption
> > > > > >
> > > > > > I believe SPs have requirements for (i) and (ii) and don't
> > > > > > have a problem with using preemption, which is an existing
> > > > > > TE mechanism.
> > > >
> > > > > Not all SPs assume the use of preemption.  So the default BC
> > > > > model should not assume ('require') the use of preemption to
> > > > > operate efficiently.
> > > >
> > > > Yes, that's correct. I'd prefer a default BC model where
> > > > preemption is an optional add on instead of a mandatory feature.
> > > >
> > > > Regards, Rüdiger
> > > >
> > > >
> > > >
> >
> >
> > _________________________________________________________
> > Francois Le Faucheur
> > Development Engineer, IOS Layer 3 Services
> > Cisco Systems
> > Office Phone:          +33 4 97 23 26 19
> > Mobile :               +33 6 19 98 50 90
> > Fax:                   +33 4 97 23 26 26
> > Email:                 [email-masked]
> > _________________________________________________________
> > Cisco Systems
> > Domaine Green Side
> > 400, Avenue de Roumanille
> > 06 410  Biot - Sophia Antipolis
> > FRANCE
> > _________________________________________________________
> >

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 16 Jul 2002 08:26:46 +0900

Neil, Ruediger,

Is it acceptable to you if the model:
         - can be used without preemption
         - works "reasonably" well without preemption (but not perfectly ie 
does not achieve all the other goals simultaneously)
         - may involve preemption to achieve all other goals
?

thanks

Francois

At 08:03 16/07/2002 +0900, Francois Le Faucheur wrote:
>         - when used without preemption, it works reasonably well , but 
> not perfectly. ie it achieves bandwidth efficiency and avoids QoS 
> degradation. but it cannot provide complete isolation.
>
>preemption, it can provide isolation, but this is at the cost of very 
>large inefficiencies.
>
>preemption . So, in the specific context of selection of a Default BC 
>Model for DS-TE, we must keep it mind that the exercise is all about 
>picking a good compromise (must work without preemption, but may have to 
>involve preemption to achieve some particular combination of goals).
>

---

From: "Dimitry Haskin" <[email-masked]>
Date: Mon, 15 Jul 2002 21:38:10 -0400

Francois,

> not

Sorry, I'm not getting it. It would help if you explain how to make the
RD model to work efficiently avoiding QoS degradation without using
preemption.

> large

Why so? Would you elaborate on these "very large inefficiencies"?  So
far it has appeared to me that MAM may do pretty well with all 6 goals
that you so well enumerated. However this would not be the first time
that I'm so confused ;)

Thanks,
  Dimitry

> Model

---

From: Sasha Ratkovic <[email-masked]>
Date: Tue, 16 Jul 2002 17:52:44 -0700

Few clarification questions. Are Bandwidth Constraints expected
to be used not only for the (LSP) admission control purpose but also
for coherently configuring packet queuing/scheduling discipline,
by the supporting device?

If not, what are the requirements for the queuing/scheduling
discipline deployed by the device?

Thanks,
Sasha

Francois Le Faucheur wrote:
>         - works "reasonably" well without preemption (but not perfectly 
> ie does not achieve all the other goals simultaneously)
>>         - the Russian Dolls model does not "mandate" preemption. It 
>> can certainly be used without preemption.
>> Now, the MAM model, can also work without preemption. When used 
>> without preemption, it can provide isolation, but this is at the cost 
>> of very large inefficiencies.
>>
>> preemption, there are other goals which are kind of pushing towards 
>> use of preemption . So, in the specific context of selection of a 
>> Default BC Model for DS-TE, we must keep it mind that the exercise is 
>> all about picking a good compromise (must work without preemption, but 
>> may have to involve preemption to achieve some particular combination 
>> of goals).
>>