Subject: Example of LOM usage

From: "Lai, Wai S (Waisum), ALABS" <[email-masked]>
Date: Wed, 4 Jun 2003 15:55:31 -0500

This is a response to the request for an example of LOM usage by
service providers in per-link per-CT overbooking.

Suppose link0 has 100 units (e.g., Mbps of link bandwidth), of which
say 30 is allocated to CT0, and 70 to CT1.  Similarly, link1 has 500
units, of which 150 is to CT0, and 350 to CT1.  That is, with 30%/70%
allocation for both links, the bandwidth constraints are in the same
proportion for both.  Then, in going from link0 to link1, CT0 sees an
increase from 30 to 150, while CT1 sees an increase from 70 to 350.

To get a feel for the change in per-CT overbooking needed for the two
links, at a very high level, we use the simple Erlang formula, assuming
1% LSP blocking for both CT0 and CT1.  (Obviously, this is very very
crude, without any consideration for sharing - but the idea is to
see the scaling effect of link speeds, to be explained below.)
 30 units support an offered load of  20.3 units (68% utilization)
150 units support an offered load of 131.6 units (88% utilization)
 70 units support an offered load of  56.1 units (80% utilization)
350 units support an offered load of 326.2 units (93% utilization)

With only 30 units in link0, CT0 has a much smaller overbooking to
start with.  Thus, CT0 should see a proportionally bigger increase
in overbooking in link1, as the utilization increases by 20% from
68% to 88%.

OTOH, CT1 has 70 units in link0 and can work with a higher overbooking.
Thus, CT1 should see a proportionally smaller increase in overbooking
in link1, as the utilization increase is much smaller, by 13% from 80%
to 93%.

In summary, depending on the relative traffic size, per-CT overbooking
may need to be proportionally different, even with LSPOM and LSOM in
use.  This is because different CTs may see different scaling effects
when link speeds change.  To support application scenarios like this,
the use of LOM is needed.

Given that LOM is to be retained, I agree with Jerry that we should
leave LOM as is and not progress it as a separate effort.  Thus, I
would like to see some discussion on how LOM could be simplified:
http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00321.html
This proposal is FULLY backward compatible with existing TE.

The formulation currently described in existing drafts is complicated
with the use of different formulas in different components.  This will
lead to operational complexity, as well as operational errors such as
misconfigurations.  The above proposal does NOT call for a reinvention
or redefinition of the overbooking model, rather, just a simplification
of what already exists by a more coherent and seamless integration.

Thanks, Wai Sum

---

From: Dimitry Haskin <[email-masked]>
Date: Wed, 4 Jun 2003 19:54:36 -0400

Lai,

I understand that a provider may want different per CT overbooking ratios on
different links. However I still fail to understand why LOM would be
required to provide a good service in such a configuration. Can you clarify?

Thanks,
  Dimitry

> -----Original Message-----
> From: Lai, Wai S (Waisum), ALABS [mailto:[email-masked]]
> Sent: Wednesday, June 04, 2003 4:56 PM
> To: [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: Example of LOM usage
> 
>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 5 Jun 2003 14:15:24 +0100

Dimitry,

>> required to provide a good service in such a configuration. 

I believe we have already discuss when LOM is required or not and
concluded on that. Quoting from your message:
>> Francois,
>> 
>> Thanks for your clear explanation. What has escaped me 
>> before is that LOM is
>> useful only for those cases where both of the following must be true:
>> 
>>  1) CTs of the same link have different overbooking ratios.
>>  2) The amount of reservations in one CT must precisely 
>> effect reservable
>> bandwidths in other CTs of the same link.
>> 
>> If I am correct, then it is quite possible to support 
>> different overbooking
>> ratios per CT per link without LOM, provided that 2) is not 
>> required (or at
>> least not with the same level of precision that LOM can provide).
>> 
>> Thanks,
>>  Dimitry

To put the same thing in a different way:
	- if you don't need per-CT-per-link ratios, you do NOT need LOM
	- if you need per-CT-per-Link ratios and can tolerate some
inaccuracy in how a CT affects the global constraints (which I think you
also refer to as allowing some degradation on some CTs in your
discussion with Sanjaya), then you do NOT need LOM.
	- if you need per-CT-per-Link ratios and want accuracy in how a
CT affects the global constraints, then you do need LOM.

So the points I think you're getting at are that:
	1) needing per-CT-per-Link ratios does not always mean you need
LOM
	2) from your experience:
	- most SPs won't need per-CT-per-link ratios
	- the few SPs who may need per-CT-per-link ratios are likely to
tolerate some inaccuracy in bookeeping over the aggregate constraint,
Therefore the case for LOM is very slim.

Right?

Cheers

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 5 Jun 2003 14:58:37 +0100

Waisum,

I think there is agreement that the fundamental theoretical reason why,
ideally, one way want to have different per-CT overbooking ratios on
different links is because a number of things don't grow linearly (like
the erlang formula).
Thanks for giving a quantified example illustrating the distortion.

But the input I am personally after is: are there service providers out
there who are likely to be really after that level of 2nd order of
optimisation in the next few years? My impression is that it is
interesting enough for an operator to try come up with the right
formula/heuristics for factoring some LSP size overbooking and some Link
size overbooking with a single class in regular TE today. When moving to
DS-TE, operators will have to extend the formulas/heuristics for LSP
size overbooking on a per-CT basis, so trying to factor it a second
level of distortion via a per-CT-per-link overbooking tweak seems a far
stretch in practise. Obviously, I could be wrong. But we still haven't
heard an operator saying he is likely to be interested in that level of
optimisation for DS-TE. 

This is also discounting Dimitry's point, thet operators could even do
that without LOM anyway if they accepted to tolerate some inacuracy on
the aggregate constraint.

Cheers

Francois

>> Sent: 04 June 2003 22:56

---

From: Dimitry Haskin <[email-masked]>
Date: Thu, 5 Jun 2003 11:27:02 -0400

Francois,

Correct, these are points that I'm making.  A minor correction is that I'm
not claiming that "most SPs won't need per-CT-per-link ratios". Nevertheless
the second bullet in point 2 is largely correct.

There seems to be a persistent impression that use of LOM (as currently
specified) is absolutely necessary when different per-CT-per-link
overbooking ratios are required whereas the quite opposite is true in
practice. This level of confusion that LOM creates seems disproportional to
its dubious value. This is why removing it from the base spec appears to be
a desirable way to proceed.

Dimitry

> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: Thursday, June 05, 2003 9:15 AM
> To: Dimitry Haskin; Lai, Wai S (Waisum), ALABS; [email-masked]
> Subject: RE: Example of LOM usage
> 
> 
> Dimitry,
>

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Thu, 5 Jun 2003 12:41:09 -0500

Francois, All,

> optimization in the next few years? 

Wai Sum has given a good example of how/why LOM is needed, this is what we all were asking for in support of keeping LOM as is.  You call the effect '2nd order optimization', I don't think so, the differences can easily be above the 'tweaking threshold'.

> My impression is that it is
> stretch in practice. Obviously, I could be wrong. But we still haven't
> optimization for DS-TE.

Yes, you just heard a reasonable example of the need, from a SP who is likely interested in applying LOM as Wai Sum has illustrated.

> This is also discounting Dimitry's point, that operators could even do
> that without LOM anyway if they accepted to tolerate some inaccuracy on

I'm a little baffled by this whole discussion.  A reasonable question was asked to provide justification for LOM.  In the ensuing discussion, most agreed that LOM is not complicated, and we have been given some reasonable examples of why/how it would be applied.  I see no reason to 'tolerate inaccuracy' if it is simple to avoid.

We've also agreed to progress LOM, either as is or 'split it off'.  There are still lots of questions surrounding the idea of splitting off LOM into a parallel effort.  Since LOM is already in the Proto spec, that is the easier option.  There does not seem to be a lot of justification now for splitting it off, especially given that its use has been illustrated.  Let's go with leaving it in, as is, and move on.

Also, I would observe that some aspects of the proposed 're-definition' of LOM, as described in http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00321.html, could be done within a given SP network without any changes to Proto or anything else.  All a SP needs to do is set LSPOM=1, LSOM=1.  Then

LOM'c = LSOM * LSPOMc * LOMc = LOMc

This would simplify the use of 3 types of overbooking in a SP network, would allow per-CT overbooking as well as per-link overbooking, and to me is a further justification to retain LOM as is.

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 10 Jun 2003 15:24:54 +0100

Jerry,

<clip>
>> I'm a little baffled by this whole discussion.  A reasonable 
>> question was asked to provide justification for LOM.  In the 
>> ensuing discussion, most agreed that LOM is not complicated, 

I am losing track as to whether LOM is declared complicated or simple ^)

In any case, as mentioned before, the point at stake is not whether it
is inherently simple or complicated. (FWIW my take is that it is pretty
much as simple as could be to do what it has to do). The point at stake
is: does the extra functionality justifies the extensions (like the
extra IGP extensions for example) when we had been designing DSTE very
carefully to minimise IGP impact so far.

>> and we have been given some reasonable examples of why/how 
>> it would be applied. 

So, we've been calling for input on the whole list several times for who
would/may have a practical case for this and all we got is one single
input (which considered potential pros based on Erlang's formula but BTW
did not discuss potential cons on the practical/operational side such as
managing Nb_of_CTs-times-Nb_of_links additional configurable parameters,
additional IGP information). 

Based on this level of input, I wouldn't say that there is a clear
justification for the extra functionality which would justify the
corresponding extensions.

<clip>
>> There are still lots of questions surrounding the 
>> idea of splitting off LOM into a parallel effort.  

I sent a message earlier specifically on this recurring statement.
The proposal is to take the text that is currently in -proto-, -russian
and -mam (and on MAR if you want) on LOM and group that in a separate
document which could then go as Experimental.
It would be the same text.
What exactly are the questions surrounding this idea?

>> Since LOM 
>> is already in the Proto spec, that is the easier option.  
>> There does not seem to be a lot of justification now for 
>> splitting it off, especially given that its use has been 
>> illustrated.  Let's go with leaving it in, as is, and move on.
>> 

To me, and I suspect to the other folks who argued for taking LOM out,
the level of input (or lack of) we got so far is actually indeed
justification for taking it off the main specs. And even, at least to
me, justification to drop it altogether.

So, we really see things differently here. 

Documenting LOM as Experimental is an attempt at a compromised approach
to try move ahead considering this disagreement. It would allow folks
who see it as something worthwhile to have it documented so it can be
experimented with, and even easily added to standards track in some
future if backed by experience. It would allow folks who question the
practical use of LOM to see a leaner DS-TE solution (at least to start
with). 

Assuming we can close-off the potential questions you may have
surrounding the idea of splitting LOM in a separate document, could you
live with this compromised approach of an Experimental track for LOM?

Thanks

Francois

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 10 Jun 2003 12:20:58 -0500

Francois,

> live with this compromised approach of an Experimental track for LOM?

In the interest of moving ahead, I'm OK with the compromise to split off LOM from the Proto and BC drafts, and progress it separately on an Experimental track.  

However, I do not agree that the starting point for the separate effort on LOM should be the current proposal.  While I believe the concept of having a separate per-link, per-CT adjustment for overbooking, such as proposed with LOM, is worth pursuing, I also believe that the particular implementation proposed in Proto is problematic, and needs a re-work.  In particular, 

1. It's not at all clear what 'normalized CTc' really means: it's not reserved BW, it's not overbooked bandwidth, what is it?  It's not a physical quantity, which makes it abstract and confusing.

2. The router reserves Tspec(LSPc) (i.e., reserved(LSPc)=Tspec(LSPc), what does it do with normalized CTc?

3. It's not at all clear what SUM [normalized_CTc] should be constrained by.  Neither Maximum Reservable Bandwidth (MRBW) nor Maximum Link Bandwidth seem correct.

4. It's not at all clear how to set BCc in terms of normalized_CTc, how should that be done, and how do the BCs relate to MRBW?

If you can shed any light on these issues 1 --> 4, with some specific numerical examples, please do.

It is much easier to understand physical quantities like reserved_CTc, what they should sum to (MRBW), how they related to BCs, etc.

I think the concepts proposed in the post on June 1 http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00321.html have merit, and should be considered in the re-initiated effort on LOM.  Wai Sum and I have expanded this proposal in an I-D that we will soon submit for discussion.  The proposed approach is coherent, I believe, while the current approach is not.  I think the I-D with our proposal for LOM should be considered in this effort.

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 11 Jun 2003 10:27:09 +0100

Hello Jerry,

>> In the interest of moving ahead, I'm OK with the compromise 
>> to split off LOM from the Proto and BC drafts, and progress 
>> it separately on an Experimental track.  
>> 

So we'll update asap the -proto, -russian and -mam drafts:
	- (i) removing all the LOM staff and 
	- (ii) reflecting our agreement regarding the use of Max
Reservable Bandwidth

>> However, I do not agree that the starting point for the 
>> separate effort on LOM should be the current proposal.  
>> While I believe the concept of having a separate per-link, 
>> per-CT adjustment for overbooking, such as proposed with 
>> LOM, is worth pursuing, I also believe that the particular 
>> implementation proposed in Proto is problematic, and needs a 
>> re-work.  In particular, 
>> 
>> 1. It's not at all clear what 'normalized CTc' really means: 
>> it's not reserved BW, it's not overbooked bandwidth, what is 
>> it?  It's not a physical quantity, which makes it abstract 
>> and confusing.
>> 
>> 2. The router reserves Tspec(LSPc) (i.e., 
>> reserved(LSPc)=Tspec(LSPc), what does it do with normalized CTc?
>> 
>> 3. It's not at all clear what SUM [normalized_CTc] should be 
>> constrained by.  Neither Maximum Reservable Bandwidth (MRBW) 
>> nor Maximum Link Bandwidth seem correct.
>> 
>> 4. It's not at all clear how to set BCc in terms of 
>> normalized_CTc, how should that be done, and how do the BCs 
>> relate to MRBW?
>> 
>> It is much easier to understand physical quantities like 
>> reserved_CTc, what they should sum to (MRBW), how they 
>> related to BCs, etc.
>> 
>> I think the concepts proposed in the post on June 1 
>> have merit, and should be considered in the re-initiated effort 
>> on LOM.  Wai Sum and I have expanded this proposal in an I-D that 
>> we will soon submit for discussion.  The proposed approach is
coherent, 
>>I believe, while the current approach is not.  I think the I-D with
our 
>> proposal for LOM should be considered in this effort.

Since it no longer impacts progress of the base DS-TE specs, I don't see
a major issue in reopening the discussion on what is the best LOM
solution, and in your proposal being considered.

I think the current LOM solution which we've had stable for a long time
in our Working Group documents is the most natural starting point until
it is actually shown "problematic" and that another proposal is
superior. So let's have the discussion first on the LOM approaches
before switching to a new proposal.

In the very short term, I'd like to focus on issuing the base specs. So
I'll get back to your points above re current LOM approach a little
later and will also look into your proposal in more details then.

Thanks

FRancois