RE: DS-TE overbooking model - Not that complicated

["sanford goldfless" <sandy9@rcn.com>]

Francois, all --

Before closing the door on LOMs, I'd like to ask that we address the
following  issues for completeness in stating the DS-TE overbooking
model. (Hope this isn't too big a post.)

1) A precise definition of "per-CT overbooking".  Link overbooking
allows total reservation to exceed the link size.  Which quantity does
CT overbooking exceed:  the expected load for the CT?  the advertised
admission constraint for the CT?  or perhaps any current reservation for
the CT, whenever the reservation total for all CTs has reached Max Link
(i.e., admission for certain CTs is closed whenever the link becomes
overbooked)? 

I think that what we've been talking about so far is accepting
reservations that exceed the expected load for the CT. 
  
2) An explicit statement on overbooking and BC usage. The nested values
in the RD BC model are primarily for bandwidth sharing among CTs, rather
than for "overbooking" as such.  However, BCs in RDM implicitly
advertise limits on link overbooking, since they are aggregate
bandwidths across sets of CTs, which may or may not exceed the link
size. In fact, the value for the total set, BC0, has the same semantic
as Max Reservable, as you say.  Max Reservable expresses the link
overbooking factor.

Would it be too much of a change to add a per-CT capability directly to
this overbooking semantic for the RD model? In order to allow different
CTs to exceed their expected loads to differing degrees, let the user
simply include the allowed excess in each case within the appropriate BC
value.  For example, on a link where Max Link = 100, Max Reservable =
150, and there are two CTs, one voice one data, to allow data to
overbook its expected load but not voice, set BC1 = 50 and BC0 = 150
when the expected load is 50 for each.

For MAM, the current definition update doesn't currently have a
reference to allowed overbooking in respect to BC values (although it
does in respect to total reservation).  But as for RDM, adding the
explicit option to include an overbooking allowance in each BC doesn't
appear to contradict the MAM definition.  

As BCs are by definition advertised (and set) per link, DS-TE would have
a per-link-per-CT overbooking capability through them, if this is
correct.  

3) A precise definition of LSP Size Overbooking. I think this is the
general understanding: In LSP Size Overbooking, LSPs of a class that can
be overbooked reserve less than their corresponding service
specifications explicitly call for, so that enough LSPs of that class
can be accepted until the capacity held for the expected load is
reached.  Anything more?

4) LSP Size Overbooking and DiffServ resources.  That it is suitable for
a network-wide approach to per-CT overbooking but not to a per-link
approach  seems to me not to be the only drawback in LSP Size
Overbooking . It also upsets the relationship between bw reservation
signaling and real-time adjustment to scheduling parameters that some
networks want to maintain. 

This is especially so when LSPs within a particular CT may vary greatly
in size and where a single LSP in that CT can reserve an amount that is
significant to the scheduler's ability to guarantee bw to the CT as a
whole. Sure, *after* the entire set of LSPs for a CT have been set up,
the end result might be the same as using LOMs:  CAC will allow enough
LSPs in so that the actual load on the CT will approach the expected
load.

But to guarantee minimum bw for an LSP or for a CT as its LSPs are set
up over time, there's got to be a way for upstream nodes to learn the
LSP under-sizing factor that is in use. 

I'm hoping that instead of LOMs and instead of LSP under-sizing, BC
over-sizing will be deemed sufficient to support "per-CT overbooking"!

Thanks,
Sandy
  
Sanford Goldfless
192 Fuller St
Brookline MA 02446
617-738-1754
sandy9@rcn.com


-----Original Message-----
From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org] On
Behalf Of Francois Le Faucheur (flefauch)
Sent: Tuesday, May 27, 2003 5:27 AM
To: te-wg@ops.ietf.org
Subject: DS-TE overbooking model - Not that complicated

Hello,

We have been through fairly detailed discussions on the overbooking
models, which I believe have been very useful to synch up. This involved
a lot of synching up on various terminology and concepts that come to
mind to each of us (only in slightly different form for each individual)
on the topic of overbooking. This may have generated a perception that
the overbooking model for DS-TE is fairly complex. I would like to
address this potential perception and make the case that the overbooking
model actually selected for DS-TE is (i) quite simple and (ii)
structured as minimum possible increment over existing TE overbooking
model.

Again, the DS-TE overbooking model has:
	*  two MANDATORY components :
		-A- LSP Size Overbooking
		-B- Link Size Overbooking
	* and one OPTIONAL component:
		-C- Local Overbooking Multiplier

The two main and mandatory components are actually an integral part of
the existing TE. Just they never got discussed that much explicitely in
existing TE documents, but they are fully part of TE. They are commonly
used in TE live deployments today. They have just been inherited by
DS-TE and we applied them in the exact same way. Only, they got
discussed more explicitely (eg when doing the exercise of providing CAC
formulas and "Unreserved Bw" formulas) to ensure they were understood
consistently in the context of multiple CTs. 
Note also that like with existing TE, -A- and -B- don't result in any
specific protocol extensions (ie you would have the exact same
extensions even if you decided to not support Link/LSP Size
Overbooking).
So I can't see how we could do any simpler here, short of losing
overbooking functionality as compared to existing TE.

The third component is the only one where additional complexity over
existing TE really comes in. But this all hinges on the potential
requirement for overbooking ratios on a per-CT-and-per-link basis which
was identified at some stage as a potential requirements. If there is
such a requirement, we do need something beyond Link/LSP Sie
Overbooking; no way around it. Rather than re-invent a complete
overbooking model for DS-TE, the LOM method is structured as a pure
optional increment over Link/LSP overbooking to address this
requirement. This is purely optional anyway (and may even be removed, as
being currently discussed).

So, in summary, :
	- the mandatory components of the DS-TE overbooking model are
strictly identical to the ones of existing TE (no more, no less)
	- the one optional component is structured as a pure increment
over the other components, and is required to provide a specifc DS-TE
functionality identified as (potential) requirement. If the requirement
is dropped, this component can also be dropped (we would then be left
with an overbooking model for DS-TE which is strictly identical to the
overbooking model of existing TE).

Hope this is useful.

Cheers

Francois