RE: Dropping the Local Overbooking Multiplier (LOM) method from D S-TE specs?

Hi Francois, Jerry, All!

My first preference, would be to leave the DSTE-PROTO
as it is with the following changes:
	(i)  replace the max_link_bw by max_reservable_bw
	(ii) add some more text clarifying the LOM concept

If after another week of discussions, we are still at impasse,
my second preference would be to split the LOM text out of 
the DSTE-PROTO and make it its own draft. I do have serious 
reservations about the second approach, because we are just 
deferring the problem and not addressing the issue.

Now, lets examine the issues in little more detail::-

As of now, I have heard the following concerns about the 
LOM concept (as presented in the DSTE-PROTO):

	Issue-1: LOM is a complex concept.
	Issue-2: LOM makes DSTE-PROTO difficult to read
	Issue-3: LOM is difficult to implement
	Issue-4: LOM is difficult to deploy
	Issue-5: We don't know if LOM is a useful concept

Here are my take on these issues::-

Issue-1:: In my opinion the LOM concept is the _least_
complex part of DSTE-PROTO. I think, people are confused
by the mechanics behind the co-existence of LOM, with the 
two *legacy* overbooking techniques.

DSTE-PROTO did not introduce the concept of "LSP Size
Overbooking" or "Link Size Overbooking". 
It just (i) gave formal name to the existing techniques
and (ii) ensured that the new LOM co-exists with the 
existing overbooking approaches.

The above mentioned existing overbooking techniques work
in existing non-DSTE networks (and will continue to work
in DSTE domains).

=>We can address this issue, by adding some clarifying text.

Issue-2:: DSTE is all about, providing per-CT BW control to
the network administrator. I think it makes the solution 
more complete by leaving the LOM text in.

=>We can easily solve the readability problem by adding
some clarifying text [will it be useful, if I propose some
text in this section?]

Issues-3:: I can't tell for others, but personally I think 
it is not a difficult feature to implement. After all, it
is just a multiplier!

=>Vendors don't have to implement it, if they think it is
difficult to implement the concept.

Issue-4:: When fine grained BW optimization is needed, 
the administrator will use the per-CT BW controls 
provided by the DSTE-PROTO. When dealing with a per-CT
level BW control, it is more natural to expect a per-CT
overbooking factor. After all, providers are used to
per-CoS overbooking concepts from their experience with
ATM.

=>DSTE-PROTO does not force all users to use the LOM 
concept, but provides enough per-CT control for the 
interested users.

Issue-5: I think per-CT overbooking solution (LOM) can 
be a useful tool the network administrators. It complements
the existing overbooking techniques, seamlessly.

	-When the administrator has decided to deploy DSTE, 
	obviously, he wants per-CT BW control. It is only 
	natural to expect a per-CT overbooking knob 

	-Consider a situation, where the administrator wants
	to overbook his data traffic, but does not want to
	overbook the voice traffic on the link. In this case
	max_reservable_bw knob is too coarse to be used. LOM
	can aid with this configuration.

	-In the past, some of the providers have indicated
	their plans to use per CoS overbooking techniques.


Thanks,
sanjay


 




> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[email protected]]
> Sent: Monday, June 02, 2003 11:19 AM
> To: Ash, Gerald R (Jerry), ALABS; [email protected]
> Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
> method from
> DS-TE specs?
> 
> 
> Hello Jerry,
> 
> >> -----Original Message-----
> >> From: Ash, Gerald R (Jerry), ALABS [mailto:[email protected]] 
> >> Sent: 02 June 2003 16:34
> >> To: Francois Le Faucheur (flefauch); [email protected]
> >> Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS
> >> Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
> >> method from DS-TE specs?
> >> 
> >> 
> >> Francois, All,
> >> 
> >> > The current approach is NOT complicated. Please see the 
> >> specific email
> >> > on this. 
> >> 
> >> That's your view, but I don't think it constitutes a proof 
> >> of same :-)
> >> 
> 
> Absolutely right. 
> Just like I would rather see statement saying that someone finds the
> current model rather complicated as opposed to statement saying it is
> rather complicated. 8^)
> 
> >> > Note that its two main components (Link/Size Overbooking) are
> >> > directly inherited from existing TE. These two should not 
> >> be modified in
> >> > any way so they remain backward compatible with existing 
> TE anyway.
> >> > The current model works, all formulas are documented and 
> >> we had lots of
> >> > discussion so everybody is fully synched up on it now.
> >> > I see no justification to enter a new round of let's reinvent the
> >> > overbooking model for DS-TE at this post Last-Call stage.
> >> 
> >> I expected this comment, of course.  However, DS-TE is a 
> >> *new* environment (CTs, BC models, etc.), and we should have 
> >> the right to define things within that new environment.
> >> 
> >> However, so as to not drag this out, and come to closure, 
> >> I'm OK to go with your proposed formulas, pending a final 
> >> agreement on LOM (see below):
> >> 
> >> 
> 
> Great. This should allow us to move ahead fast as soon as we make a
> final call on what to do with LOM.
> 
> >> When LOM is NOT used (i.e. LOM[i]=1)
> >> =================================================
> >> o for each value of b in the range 0 <= b <= 7:
> >>   Reserved (CTb) <= BCb,
> >> o SUM (Reserved(CTc)) <= Max-Reservable-Bw,   
> >>   where the SUM is across all values of c in the range 0 <= c <= 7
> >> 
> >> When LOM is used 
> >> ===============================
> >> o for each value of b in the range 0 <= b <= 7:
> >>   Normalized (CTb) <= BCb,
> >> o SUM (Normalized(CTc)) <= Max-Reservable-Bw,   
> >>   where the SUM is across all values of c in the range 0 <= c <= 7
> >> 
> >> "Unreserved TE-Class [i]" when LOM is NOT used (i.e. LOM[i]=1)
> >> ============================================================
> >> MIN  [
> >> [ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p ,
> >> [ Max_Reservable_Bw - SUM ( Reserved(CTb,q) ) ] for q <= p 
> >> and 0 <= b <= 7,]
> >> where:
> >> TE-Class [i] <--> < CTc , preemption p>
> >> in the configured TE-Class mapping.
> >> 
> >> "Unreserved TE-Class [i]" when LOM is used
> >> ==========================================
> >> LOM(c) x MIN  [
> >> [ BCc - SUM ( Normalized(CTb,q) ) ] for q <= p,
> >> [ Max_Reservable_Bw - SUM ( Normalized(CTb,q) ) ] for q <= p 
> >> and 0 <= b <= 7,]
> >> where:
> >> TE-Class [i] <--> < CTc , preemption p> 
> >> 
> >> > The idea of Experimental is that LOM would be neither "dead" nor
> >> > "standards". It would suggest that LOM is something we've 
> >> discussed and
> >> > documented and some people may want to play with. 
> >> Experience will tell
> >> > us what we should do with it.
> >> > Another good thing with Experimental is that I don't think 
> >> we have to
> >> > all agree that it is a useful thing as long as some people do. I
> >> > personally would have no problem in dropping LOM 
> altogether, but my
> >> > impression was that some people had a problem in dropping 
> >> it altogether
> >> > because we just don't really know whether it will be 
> >> useful or not. That
> >> > sounded like Experimental track to me.
> >> > 
> >> > Do you feel there is rough consensus to drop LOM 
> >> altogether (that would
> >> > work for me)?
> >> 
> >> I have not seen anyone give an example of where LOM is 
> >> needed.  Unless we see that, my preference would be to drop 
> >> it.  LOM is a real parameter, and at present needs to be 
> >> carried in the RSVP extensions for DS-TE.  It requires 
> >> addition aggregation constraints in the BC models.
> >> 
> >> Considerations of per-CT and hi-speed vs. low-speed links 
> >> can be easily accommodated, as I gave in an example by using 
> >> just LSPOM and LSOM (see earlier post 
> >> http://ops.ietf.org/lists/te-wg/te->> wg.2003/msg00314.html).  
> >> It seems like much more than 
> >> enough flexibility to avoid any problems, without also 
> >> further complication with LOM.  
> >> 
> >> Can anyone explain why LOM would be needed, and in 
> >> particular, give a practical example of same?
> >> 
> >> It seems to have marginal value (I don't see anyone showing 
> >> how it is needed, or really supporting it).  I think we can 
> >> agree that simplification *will* be achieved if we eliminate LOM.
> 
> We can certainly agree on that.
> 
> So let's see if we hear some justiication for LOM or not, and based on
> that we can finalise decision (hopefully within a few days) firstly to
> take LOM out of base specs, and secondly to drop altogether 
> (or document
> as Experimental).
> 
> Cheers
> 
> Francois
> 
> >> 
> >> Thanks,
> >> Jerry
> >> 
>