Issue-5: RE: Dropping the Local Overbooking Multiplier (LOM) meth od from D S-TE specs?

Hi Dimitry!,

Here is what we seem to agree on: A per-CT overbooking knob
is useful for the administrators.

Now on to your second point: per-CT overbooking can be done
without overbooking. In my personal opinion, you might have
made few wrong assumptions:

	1. Your example requires the preemption to be enabled
	in the domain; which may not be true. 

	=>LOM gives user explicit control overbooking at a 
	per-CT level, without the need to preemption.

	2. You indicated "However without LOM amount of 
	reservations in one CT may not accurately effect 
	reservable bandwidths in other CTs of the same link"

	=>Don't you think this a problem? Head-end LSR computed
	the path based on the advertised BWs per-CT [which is
	is the foundation of DSTE], will now compute a wrong
	path. 

	2. For a moment let is assume that preemption *is* 
	deployed in the domain. Can you explain me how I 
	will achieve the following [please be specific in
	what the user will need to do and the BC model in 
	use]:

		case-1: want to overbook data-traffic without
		overbooking voice traffic.

		case-2: Want to overbook the voice traffic by
		10%, but want to overbook data traffic by 40%

		case-3: want to overbook gold-traffic by 10%,
		overbook silver-traffic by 15%, overbook 
		normal-traffic by 20%

	3. Can all of the above be achieved without the 
	use pre-emption?


Thanks,
sanjay
	

		


> -----Original Message-----
> From: Dimitry Haskin [mailto:[email protected]]
> Sent: Tuesday, June 03, 2003 2:34 PM
> To: 'Choudhury, Sanjaya'; [email protected]
> Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
> method from
> D S-TE specs?
> 
> 
> Sanjaya,
> 
> Let me take you on Issue-5 ("We don't know if LOM is a useful 
> concept")
> since if we new that it is really useful it would be a good 
> reason to keep
> LOM in the base spec.
> 
> > 	-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 
> >
> 
> A per-CT overbooking knob will exist without LOM. However 
> without LOM amount
> of reservations in one CT may not accurately effect 
> reservable bandwidths in
> other CTs of the same link. So the real question is not if a per-CT
> overbooking knob is need (of cause it does) but whether there 
> are real uses
> for LOM that can not be done without LOM. Which take us to your second
> bullet.
> 
> > 	-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.
> 
> But is it really? My understanding is that in this particular case
> administrators would like to allow reservations of the voice traffic,
> presumably in its own CT, to reach its designated max level 
> regardless of
> the amount of reservations of data traffic. So LOM is no help 
> here as far as
> I can see. My educated guess is that in actual deployments a 
> priority CT
> will be admitted up to its max reservation level regardless 
> and at expense
> of the existing bookings at lower priority CTs.
> 
> > 	-In the past, some of the providers have indicated
> > 	their plans to use per CoS overbooking techniques.
> 
> Definitely so but the most likely without LOM. Service 
> providers may want to
> comment.
> 
> Regards,
>   Dimitry
> 
> 
> 
> 
> > -----Original Message-----
> > From: Choudhury, Sanjaya [mailto:[email protected]]
> > Sent: Tuesday, June 03, 2003 10:10 AM
> > To: [email protected]
> > Subject: 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
> > > >> 
> > > 
> > 
>