[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Dropping the Local Overbooking Multiplier (LOM) method from D S-TE specs?

To: "'Choudhury, Sanjaya'" <Sanjaya.Choudhury@Marconi.com>, te-wg@ops.ietf.org
Subject: RE: Dropping the Local Overbooking Multiplier (LOM) method from D S-TE specs?
From: Dimitry Haskin <dhaskin@axiowave.com>
Date: Tue, 3 Jun 2003 14:33:56 -0400
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:Sanjaya.Choudhury@Marconi.com]
> Sent: Tuesday, June 03, 2003 10:10 AM
> To: te-wg@ops.ietf.org
> 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:flefauch@cisco.com]
> > Sent: Monday, June 02, 2003 11:19 AM
> > To: Ash, Gerald R (Jerry), ALABS; te-wg@ops.ietf.org
> > Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
> > method from
> > DS-TE specs?
> > 
> > 
> > Hello Jerry,
> > 
> > >> -----Original Message-----
> > >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] 
> > >> Sent: 02 June 2003 16:34
> > >> To: Francois Le Faucheur (flefauch); te-wg@ops.ietf.org
> > >> 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
> > >> 
> > 
>
Prev by Date: RE: Dropping the Local Overbooking Multiplier (LOM) method from DS-TE specs?
Next by Date: RE: Dropping the Local Overbooking Multiplier (LOM) method from DS-TE specs?
Previous by thread: RE: Dropping the Local Overbooking Multiplier (LOM) method from D S-TE specs?
Next by thread: I-D ACTION:draft-ietf-mpls-mgmt-overview-05.txt
Index(es):
- Date
- Thread