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

From: Dimitry Haskin <[email-masked]>
Date: Fri, 12 Jul 2002 13:38:54 -0400

Francois,

Consider this posting as my input into the informal discussion that I will
no be able to attend.

The Russian Doll BC model is a  fine model in its own rights. However it may
not be suitable as the default BC model that is mandated for diff-serv
capable MPLS devices.  My concern is that, due the nested nature of its
bandwidth constraints, the RD model does not make much sense if preemption
of established LSPs is not used as a part of a given diff-serv deployment.

The question really boils down to whether support of preemption is to be
required (at least in the IETF framework) from the diff-serv capable MPLS
devices. So far support of preemption was optional. Moreover, IMHO,
diff-serv can be deployed in quite satisfactory way without use of
preemption. Furthermore, preemption of established LSPs may not be even
desirable in some deployments.

Given that the RD BC model implicitly requires use of preemption for it to
work, the posted question should be explicitly addressed one way or another
before the RD model can be selected as the model that every diff-serv
capable LR must implement.

Thanks,
  Dimitry 

> -----Original Message-----
> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Friday, July 12, 2002 5:59 PM
> To: [email-masked]
> Subject: IETF54- Informal discussion on BC Model for DS-TE
> 
> 
> Hello,
> 
> TEWG will not meet in Yokohama/IETF54.
> 
> I'd like to invite the people who will be in Yokohama and 
> have thoughts on 
> default Bandwidth Constraints model for DS-TE, to get 
> together for a very 
> informal discussion on that topic.
> 
> Let's meet in the lobby of the main hotel at 17:30pm on Monday.
> 
> See you there
> 
> Francois
> 
>

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Sun, 14 Jul 2002 22:36:38 -0400

Francois,

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

> I believe the Russian Doll model is a very good way to achieve (i) and 
> (ii).  Yes it involves preemption to do so, but that is exactly why 
> preemption was specified for (ie let some LSPs which arrive later bounce 
> earlier LSPs).

A model like RD that only works efficiently if preemption is used is problematic.  Wai Sum Lai's I-D (http://search.ietf.org/internet-drafts/draft-wlai-tewg-bcmodel-00.txt) has also pointed out some of the other issues encountered by the RD model under overload.
 
> I don't think it would make any sense to sacrifice (i) or (ii) just for the 
> sake of not using preemption.

It is possible to achieve (i) and (ii) *without* using preemption (you don't have to 'sacrifice' anything).  For example, use of dynamic bandwidth reservation together with maximum allocation is one approach (such a 'BC model' has been used in large-scale applications for many years).  

My input to the informal discussion is that a lot more discussion (and analysis) is needed before settling on a default BC model.

Jerry Ash

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 15 Jul 2002 09:21:10 +0200

Hi Jerry

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 15 Jul 2002 18:09:16 +0900

Jerry,

>It is possible to achieve (i) and (ii) *without* using preemption (you 
>don't have to 'sacrifice' anything).  For example, use of dynamic 
>bandwidth reservation together with maximum allocation is one approach 
>(such a 'BC model' has been used in large-scale applications for many years).

Could you detail this BC model?

Thanks

Francois

>My input to the informal discussion is that a lot more discussion (and 
>analysis) is needed before settling on a default BC model.
>
>Jerry Ash

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 15 Jul 2002 23:21:59 +0900

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

_________________________________________________________
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: [email-masked]
Date: Mon, 15 Jul 2002 16:38:52 +0100

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

regards, Neil

> Sent: 15 July 2002 15:22
> To: [email-masked]
> Cc: [email-masked]

---

From: Dimitry Haskin <[email-masked]>
Date: Mon, 15 Jul 2002 13:34:04 -0400

Francois,

Yes, if I had to choose between Russian Doll and Maximum Allocation models,
I would favor the latter. This is because I feel that potential QoS
degradation of a lower level service (probably the best-effort service
anyway) is preferable to arbitrary denying service to already established
flows (which by itself is an extreme case of service degradation of affected
flows).

Said that, I'm also thinking of the possibility of combining the concepts of
RDM and MAM in a single more flexible BC model with only slight complexity.
One such an approach would introduce an additional configuration parameter,
say 'nesting levels' (NL), that controls how many levels of the RD types of
bandwidth nesting is employed.

To illustrate how it may work, let's consider 3 CTs, say CT2, CT1, and CT0,
with BC2, BC1, and BC0 as respective bandwidth constraints.

Setting NL to 0 results in MAM, i.e.:
  - sum of CT0 reservations <= BC0
  - sum of CT1 reservations <= BC1
  - sum of CT2 reservations <= BC2

NL of 1 results in a combination of MAM and RDM:
  - sum of CT0, CT1, and CT2 reservations <= BC0
  - sum of CT1 reservations <= BC1
  - sum of CT2 reservations <= BC2

NL of 2 results in RDM:
  - sum of CT0, CT1, and CT2 reservations <= BC0
  - sum of CT1 and CT2 reservations <= BC1
  - sum of CT2 reservations <= BC2

This also depicted below:

NL=0:

|---BC2---->|---------BC1-------->|-------------------BC0----------->

NL=1:

|---BC2---->|---------BC1-------->
|-------------------BC0------------------->

NL=2:

|---BC2---->
|---------BC1-------->
|-------------------BC0------------------->

What do you think?

Regards,
  Dimitry

> Sent: Sunday, July 14, 2002 9:37 PM
> To: Dimitry Haskin
> Cc: [email-masked]
> Dimitry,
> have some of
> >its
> > > bandwidth taken by another CT)
> >I respectfully disagree. I believe that (i) and (ii) can be achieved
> >simultaneously with (iii). Preemption of LSPs at a lower 
> service level
> >in order to allow LSP calls at a higher service level is not the only
> >way to achieve (i) and (ii). An alternative would be to allow a
> >potential service degradation of the already established 
> LSPs at a lower
> >service level without totally removing (often in an 
> arbitrary way) any
> >particular LSP from the service. Given my example, the sum 
> of normalized
> >CT1 and CT0 reservations would be allowed to exceed BC0.
> 
> Let's see if I understand exactly what you are proposing. If 
> I understand 
> correctly, you're arguing in favor of the Max Allocation 
> model where you 
> would configure the sum of the constraints much larger than 
> the total capacity.
> For example, on a link of 100, you would configure something like:
>          - Sum (CT0) <= BC0 = 100
>          - Sum (CT1) <= BC1 = 50
> And then you are saying:
>          - you can always make full use of the link (ie even 
> if there is no 
> CT1 you can setup 100 of CT0)
>          - you can always achieve 50 worth of CT1 without 
> preemption (even 
> if you have a 100 of CT0, you will accept 50 of CT1 and then 
> CT0 will just 
> get degraded).
> 
> Is this right? or are you proposing another BC model and if 
> so can you 
> detail it for us?
> 
> Thanks
> 
> Francois
>

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Mon, 15 Jul 2002 22:07:49 -0400

Francois,

> Could you detail this BC model?

It's described already in http://www.ietf.org/internet-drafts/draft-ietf-tewg-qos-routing-04.txt.  More specifically, see Section 3.4.2 of ANNEX 3 (PDF version at http://www.research.att.com/~jrex/jerry/annex3-tewg-qos-routing-04.txt.pdf).  See also Section 3.3 for the description of dynamic bandwidth reservation and Section 3.9 for modeling results showing the effectiveness of the method.

I'll plan to write a short I-D focusing on the maximum allocation with reservation (MAR) BC model when I return from vacation (which I'm now on :-)

Thanks,
Jerry

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 16 Jul 2002 08:53:26 +0200

Francois,

my 2 cents in line.

Regards, Rüdiger

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

Effective use of bandwidth, bandwidth isolation and 
limited IGP changes are the goals I look at as most 
important.

Neil> .......but I have to point out that my
Neil> observation on pre-emption was quite general 
Neil> (so not just this DS/TE case, and it can also 
Neil> apply to other network technologies like ATM...

That would hold for me too.

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

The lack of isolation means that you'd have to 
overprovison to make sure that a reasonable amount 
of reservations of all service types is possible. 
I'm not sure whether RD without preemption provides
sufficient added value to justify the added 
operational complexity.