[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Example of LOM usage
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
>> -----Original Message-----
>> From: Lai, Wai S (Waisum), ALABS [mailto:wlai@att.com]
>> Sent: 04 June 2003 22:56
>> To: te-wg@ops.ietf.org
>> Cc: Ash, Gerald R (Jerry), ALABS
>> Subject: Example of LOM usage
>>
>>
>> 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
>>
>>