[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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