Subject: Re: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt

From: Kireeti Kompella <[email-masked]>
Date: Thu, 19 Jul 2001 10:32:24 -0700 (PDT)

Hi Amir,

(I am moving this discussion from the MPLS WG to the TE WG.)

> A few comments regarding your proposal:

Thanks for your comments, and for your careful reading!

> 1) it seems there is a typo in your draft, section 7.3. The last two

Good catch!  Even with the current "bandwidth glut", we can't afford
not to give the bandwidth back :-)

> 2) The current approach supports configuration changes without "losing
> the math". However, in your proposal, if the administrator changes the
> subscription factor after some LSPs were set up at that priority, it
> would mean that when one of these LSPs were removed you can't properly
> calculate which B' to use in the math.

This is an excellent point -- thanks for bringing it up.  Let me work
out the whole issue of config changes and repost to the list.

> 3) With your proposal, it is possible to model the current approach with
> over-subscription (with necessary modifications to TE extensions and
> CSPF code). However, under-subscription can't be modeled (due to the
> restriction in 7.1). What are the reasons for this decision?

One could of course remove the restriction.  However, undersubscription
is merely stating that you can't use the entire link bandwidth; the max
bandwidth field gives you that control directly.  If you can see a
scenario where max bandwidth doesn't provide enough flexibility, please
let me know.

> 4) It seems that this proposal (as well as others before it) doesn't
> fully address considerations for (Diffserv) inter-class(type)
> pre-emption. Since B' is computed using subscr[p], and is used at lower
> priorities (q > p) for pre-emption, IMHO an explanation of how this is
> sensible for pre-empting between classes should be accompanied.

There are two orthogonal points here.  First, how does one compare
bandwidths at different priorities, since each priority has different
oversubscription factors?  (The answer is normalization, which is not
a real answer; however, a real answer would involve probability
functions, and I've long since forgotten what those are :-)  Besides,
the notion of oversubscription is based on pragmatics rather than
mathematics; normalization just follows that trend.)

Second, does preemption make sense?  This is up to the provider;
preemption allows higher priority LSPs to pick better paths at the
expense of some network churn.

The bottom line is, a 100Mbps link can only support 100Mbps worth of
normalized bandwidth.  If you're over that limit, some LSP needs to
go.

(I'm not sure I answered your question; if not, ask again.)

> 5) Your "Current Approach" explanation is IMO the clearest and most
> concise out there.

Thanks!  I try.

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 19 Jul 2001 10:32:24 -0700 (PDT)

Hi Amir,

Thanks!  I try.

Kireeti.

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Fri, 20 Jul 2001 17:19:36 -0400

Hi Kireeti,

A few more comments on the draft:

1) First, I am surprised to see a draft describing
   bandwidth accounting (or CACing).Thought these 
   are internal to a node, implementation specific
   and should not be influenced by standards.
2) The term "priority" is kind of overloaded in 
   Section 7.1. If priority is referring to a service
   class (or a PSC as in Diffserv), then please
   change the name appropriately. Or are you inferring
   preemption priority is one-to-one mapped to the service
   class? I am assuming that is not the case.
3) I thought Class type is only useful in reducing the
   flooding information of IGP protocols and one needs
   per-class bandwidth accounting anyway. For example
   you can use different CAC parameters for the classes
   belonging to the same Class-type, but consume bandwidth
   from same aggregated pool. Therefore Class Type band
   width pool may not necessarily mean that we don't 
   need per-class bandwidth accounting.
4) Is there any reason why you did not discuss FA-LSPs or
   hierarchical tunnels, corresponding bandwidth accounting,
   bandwidth accounting of LSPs riding on the tunnels and
   overbooking?

-Sudhakar

---

From: "Amir Hermelin" <[email-masked]>
Date: Fri, 20 Jul 2001 23:29:40 +0300

Kireeti,
(thanks for correcting the WG. As tired as I was, I might as well have sent
it to the Interent Fax WG without telling the difference...)

> scenario where max bandwidth doesn't provide enough flexibility, please

WRT under-subscription: the only limitation I see in your proposal, is when
a provider would want to normalize under-subscription BW values as well. So,
for example, you'd have a normalization factor of 0.5 for 100%
oversubscribed (200% subscription factor) priorities; however, you can't
have a normalization factor of 2 for 50% under-subscribed priorities, since
the draft limits the subscription factor to be >= 100%. Removing this limit
alone might not be enough as well.

Please correct me if I'm missing something.

Regards,
	Amir.

--
Amir Hermelin                  mailto:[email-masked]
Charlotte's Web Networks Inc.  http://www.cwnt.com

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 24 Jul 2001 19:52:04 +0200

Kireeti and DS-TEers,

A few comments/thoughts:

1) Oversubscription
As Jim already clarified, other DS-TE approaches do support 
oversubscription. They assume that tunnel bandwidth can effectively 
directly be configured as "normalised bandwidth" ie an oversubscription 
factor can be applied when selecting the "bandwidth" parameter of the 
tunnel. Then nothing further has to be done to support oversubscription.

The one functional difference I can see between the two oversubscription 
approaches is that your approach allows to have differnet oversubscription 
ratios on different links (ie a given LSP may use 200Mb/s of normalised 
bandwidth on a link and use 300Mb/s on another link). Some of us discussed 
this a while back and we felt that while it may be a nice-to-have in some 
cases , it was not a strong requirement which justified the extra 
complexity of dealing with oversubcription ratios & normalised bandwidth on 
every link configuration and in every advertisement.

Do you see a strong requirement for being able to fine-tune 
oversubscription on a per-link basis for the same given LSP?
Anyone from Service Provider community could give us input on this?

Also, to size the bandwidth of a TE tunnel, I believe Service providers 
often first collect traffic measurement and then massage this according to 
their own black magic (ie look at peak or average or percentile or mixture, 
compute those over different time windows,...). All this exercise can 
pretty much be viewed as "how do I summarise all this information about 
traffic into a single representative parameter -which is bandwidth- ?". So, 
I look at all of this as already somehow trying to come up with a 
"normalised bandwidth". Since "oversubscription" is one of the many black 
magic parameters and part of the normalisation, it seems fairly natural to 
factor it as part of this exercise of deciding the size of the tunnel in 
the first place. No?

2) Migration from existing TE
It would be very useful if you could describe how you see migration from a 
network running existing TE (with existing TE advertisement) into running 
DS-TE as per your proposal.
Since you are proposing to deprecate the existing TE extensions, are you 
assuming a flag day or are you assuming that a "new" implementations 
support both extensions (and then what do I advertise in the old extensions)?

3) Bandwidth Constraints

As described in 2.2 of the Requirement draft, there are a combination of 
requirements which lead us to define "Russian Dolls" bandwidth constraints 
(ie constraint on CT2, then on CT2+CT1, then on CT2+CT1+CT0) rather than 
simple bandwidth constraint per class/Class-Types..
If I take a typical 3 class (EF/Voice, AF/Data-Premium , BE/Best-Effort) 
network, then I think it would be reasonable for QoS motivations to want to:
	- limit EF traffic on its own (eg to 60%.)
	- limit AF traffic DEPENDING on how much EF traffic is set-up: eg. limit 
AF to 80% if there is no EF traffic , but obviously limit AF below if there 
is some AF traffic (eg. limit EF+AF to 80%)
	- limit Best Effort traffic DEPENDING on how much EF and AF is set-up: eg. 
limit BE to 100% if there is no EF&AF, but limit BE below if there is EF 
and AF traffic.
(the above discussion assume we're talking in "normalised" bandwidth).
No?

I could not see how one could achieve the above with your proposal. Do you 
see a way to do this?

In other words, I think with your proposal I could limit normalised EF to 
40% , normalise AF to 40% and normalised BE to 20%. But if there is no EF 
currently, I cannot accept more AF than 40% which seems wasteful.

However, I think your proposal could be modified to achieve this without 
changes in the advertisements, simply by changing the admission control 
formulas to reflect the "Russian Doll" relationship of bandwidth constraints.

4)Multiple Computations on Head-End
I believe this is what Jim has already pointed out in one of his comments:
Not being able to predict bandwidth means a Head-End doing multiple 
computations simply computes as accurately [ or as inaccurately '^) ] as 
any other Head-End (when it could have computed more accurately).

5) Cross-Class Preemption
Just to avoid confusion I believe by "Cross-Class Preemption" you mean the 
ability to have multiple classes/class-types use the same preemption level 
(as opposed to "Preemption across Class-Types" as defined in 2.5.2 of DS-TE 
Requirements).
I agree that there is currently no identified requirement for "Cross-Class 
Preemption". As a matter of fact, it's not identified as a requirement in 
the current DS-TE Requirements document.
Input from SP on this is welcome.
Just want to clarify that DS-TE proposal happens to support it naturally if 
one wants to do it, but obviously it does not have to be used.

Cheers

Francois

PS: I'll be out of email from now on until the IETF, so I'll only be able 
to resume discussions over there. Someone will probably have come up with a 
fifth proposal by then.
_______________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 89 108 159
Fax:                   +33 4 97 23 26 26
Email:                  [email-masked]
_________________________________________________________________
Cisco Systems Europe
Domaine Green Side
400, Avenue de Roumanille
Bâtiment T3
06 410   BIOT
SOPHIA ANTIPOLIS
FRANCE
_________________________________________________________________