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

> -----Original Message-----
> From: Choudhury, Sanjaya [mailto:[email protected]]
> Sent: Wednesday, June 04, 2003 9:33 AM
> To: [email protected]
> Subject: 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.

:)) .. perhaps "without LOM".

>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.

Not at all. An alternative to preemption would be to allow degradation of
lower priority services, which IMO could be preferred to outright
preemption.
> 
> 	=>LOM gives user explicit control overbooking at a 
> 	per-CT level, without the need to preemption.

Which imposes on the bw isolation objective (ie. a higher priority CT should
not have some of its bw taken
by a lower priority CT).

> 
> 	2. You indicated "However without LOM amount of 
> 	reservations in one CT may not accurately affect 
> 	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.

Not at all. Path computations are based on the advertised "unreserved bw"
for each CT/link. So it is local matter for advertising nodes to correctly
reflect what they are planning to accept at a particular CT.

> 
> 	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%

What is the catch? Why would not you do just that? I.e., overbook each CT
independently to their respective designated level. 
Or, I supposed, you have missed the aggregate constraint from you examples
which would make them slightly more illustrative. Not that I want to help
you to make your case ;)

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

To reiterate, yes it can. We had a long discussion on that a while ago in
respect of RD vs MA models.
> 
> 
> Thanks,
> sanjay

Regards,
  Dimitry
> 
> 		
> 
> 
> > -----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
> > > > >> 
> > > > 
> > > 
> > 
>