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

From: Dimitry Haskin <[email-masked]>
Date: Mon, 2 Jun 2003 12:00:28 -0400

I agree with Francois. Let's remove LOM from the base spec and not to
venture on another round of unnecessary redefinitions of the base spec.

As a side note, I would not be too upset if no separate LOM spec follows any
soon. I'd let someone who feels that there is a real practical need for LOM
to pick up the LOM torch.

Dimitry

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: Monday, June 02, 2003 9:02 AM
> To: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
> method from
> DS-TE specs?
> 
> 
> Jerry,
> 
> >> -----Original Message-----
> >> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> >> Sent: 02 June 2003 14:02
> >> To: Francois Le Faucheur (flefauch); [email-masked]
> >> 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,
> >> 
> >> > no one has expressed objections to taking LOM out of the base
> >> > spec to move it to another document.
> >> 
> >> I believe Sanjay objected, 
> 
> I am sure will hear from Sanjay soon, but quoting from his email:
> >> 	I am not against moving the LOM feature into its own draft, 
> Doesn't sound like an objection to me.
> 
> So I think it is fair to say that noone has expressed any 
> objection (at
> this stage anyway).
> 
> >>and I think he made a good point. 
> >>  Either we should agree to drop LOM completely (no 'separate 
> >> document' and/or Experimental track for LOM), or leave it 
> >> in.  If it is progressed as a separate document/Experimental 
> >> track, this would complicate backward compatibility for all 
> >> the BC models.
> >>
> 
> Whether we keep the text on LOM distributed over -proto, 
> -russian, -mam
> (and perhaps in MAR if you have added that in) as it is today 
> or whether
> we redistribute it into a single standalone document does not affect
> backward compatibility. We're only talking about 
> redistributing the same
> text in a different set of documents so we can make one document
> Experimental.
>   
> >> > Based on this, unless we hear different opinions shortly, 
> >> my proposal
> >> > will be to:
> >> > 	- issue the next versions of -proto, -russian and -mam without
> >> > LOM, so these can go to IESG Last Call promptly (Standards 
> >> for -proto,
> >> > Experimental for -russian and -mam)
> >> 
> >> Wai Sum and I have already expressed a different opinion in 
> >> the proposed re-definition of LOM.  Before we agree to drop 
> >> the LOM feature, we'd like to see some discussion on the 
> >> alternative proposal to simplify the rather complicated 
> >> 3-way approach to overbooking that now exists.  See below.
> 
> The current approach is NOT complicated. Please see the specific email
> on this. 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.
> 
> >> 
> >> You've also forgotten to mention -mar in the above.
> >> 
> >> > 	- issue a separate document (-lom) on LOM which can be
> >> > progressed in Experimental track.
> >> 
> >> As above, I'm against a separate Experimental track for LOM, 
> >> because this would complicate backward compatibility for all 
> >> the BC models.  Otherwise, we need to explain how LOM can be 
> >> introduced into the BC models later on, and avoid a 
> >> transition/interoperability problem.  It seems that with the 
> >> proposed separate track, LOM is functionally dead, but not 
> >> officially dead.  I think we should either officially kill 
> >> LOM, or retain it (but perhaps re-defined).
> >>  
> 
> 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 concensus to drop LOM altogether 
> (that would
> work for me)?
> 
> Cheers
> 
> Francois
> 
> >> > Please let me know if you have concerns with this proposal.
> >> 
> >> Yes, 2 concerns:
> >> 
> >> 1. As above, if LOM is progressed separately, we need to 
> >> explain how LOM can be introduced into the BC models later 
> >> on, and avoid a transition/interoperability problem.  I 
> >> think it would be preferable to officially kill LOM, rather 
> >> than leave it in the proposed 'separate track'.
> >> 
> >> 2. Before we agree to drop the LOM feature, we'd like to see 
> >> some discussion on the alternative proposal to redefine LOM 
> >> (to LOM'), in order to simplify the rather complicated 3-way 
> >> approach to overbooking that now exists:
> >> 
> >> LSPOMc = LSP overbooking multiplier for CTc
> >> LSOM = link size overbooking multiplier
> >> LOMc = local overbooking multiplier for CTc
> >> 
> >> If LOM is retained, Wai Sum and I propose to redefine LOM 
> >> (calling it LOM') to provide an overall simplification of 
> >> this 3-way overbooking complexity, as follows.
> >> 
> >> Define:
> >> 
> >> LSPOMc = LSP overbooking multiplier for CTc
> >> LSOM = link size overbooking multiplier
> >> LSOM = maximum reservable bandwidth/maximum link bandwidth
> >> LOMc = local overbooking multiplier for CTc (original 
> >> definition of LOMc)
> >> LOM'c = redefined local overbooking multiplier LOMc for CTc
> >> LOM'c = LSOM * LSPOMc * LOMc
> >> 
> >> Given:
> >> requested LSP CTc = RSVP-TE Tspec LSP bandwidth specified in TLV
> >> 
> >> Then the following general equation applies:
> >> reserved CTc = requested LSP CTc/LOM'c                       (1)
> >> 
> >> wherein there are several cases of equation (1) for reserved CTc:
> >> 
> >> 1. Link Size Overbooking only:
> >>     LSPOMc = 1, LOMc = 1, for all c
> >>     LOM'c = LSOM, or equivalently
> >>     reserved CTc = requested LSP CTc/LSOM = requested LSP CTc/LOM'c
> >> 2. LSP Size Overbooking only:
> >>     LSOM = 1, LOMc = 1, for all c
> >>     LOM'c = LSPOMc for all c, or equivalently
> >>     reserved CTc = requested LSP CTc/LSPOMc = requested 
> LSP CTc/LOM'c
> >> 3. Both Link Size Overbooking and LSP Size Overbooking:
> >>     LOMc = 1, for all c
> >>     LOM'c = LSOM * LSPOMc, or equivalently
> >>     reserved CTc = requested LSP CTc/(LSOM * LSPOMc) = 
> >> requested LSP CTc/LOM'c
> >>  4. LOM in conjunction with the above cases 1, 2, or 3
> >>     reserved CTc = requested LSP CTc/LOM'c
> >> 
> >> In this model, the aggregate constraint becomes:
> >> 
> >>  o SUM (Reserved(CTc)) <= MLBW                               (2)
> >>      for all "c" in the range 0 <= c <= (MaxCT-1)
> >> 
> >> We believe that this simplification, as summarized in 
> >> equations (1) and (2) above, is worthwhile if LOM is retained.
> >> 
> >> Thanks,
> >> Jerry & Wai Sum
> >> 
>

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Mon, 02 Jun 2003 12:10:20 -0400

I agree with Francois and Dimitry.

Thanks,
Siva

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Tue, 3 Jun 2003 10:09:46 -0400

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

> Sent: Monday, June 02, 2003 11:19 AM
> Hello Jerry,
> >> Sent: 02 June 2003 16:34
> >> > 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
> >> > The current model works, all formulas are documented and 
> >> we had lots of
> >> 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> 
> >> 
> >> > 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
> >> > 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
> >> 
>

---

From: Dimitry Haskin <[email-masked]>
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.

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

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

> 	their plans to use per CoS overbooking techniques.

Definitely so but the most likely without LOM. Service providers may want to
comment.

Regards,
  Dimitry

> From: Choudhury, Sanjaya [mailto:[email-masked]]
> Sent: Tuesday, June 03, 2003 10:10 AM
> To: [email-masked]
> D S-TE specs?

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Wed, 4 Jun 2003 09:47:35 -0400

Hi!
comments in-line.

> Sent: Tuesday, June 03, 2003 7:28 PM
> To: [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS; Francois Le Faucheur 
> (flefauch); Lai,
> Wai S (Waisum), ALABS
> All,
> I had proposed earlier:
> > Can anyone give a practical example of where LOM is needed? 
> > Unless we see that, my preference would be to drop it.   
> 
> Since posting that, some examples have been given (on the 
> list and privately) that perhaps illustrate how LOM can be 
> used in practice.
> 
> Furthermore, based on the discussion so far:
> 
> 1. many people support leaving LOM in because they're 
> reluctant to give up the extra flexibility (even though they 
> don't offer specific supporting examples).
> 2. many people feel that the LOM extension is very simple, 
> therefore why the concern, just leave it there.
  
  And possibly a third category:
  3. people who think the LOM extension is relatively simple
  and think LOM has potential usage. 
  [On complexity issue : see my previous e-mail,
   For specific example: see my previous e-mail on issues and
				 the e-mail response to Dimitry's e-mail]

> 
> Also, I argued against having LOM progressed separately, I 
> think that would just complicate matters, and leave the BC 
> models, Proto extensions, etc. in a state of limbo (possible 
> awaiting a LOM extension later).  I had argued to either keep 
> LOM, or drop LOM, but not leave it in the 'in between' state.
> 
> Overall, I don't think the case has been made to drop LOM, 

  Personally, I agree with this view [given that LOM is already
  an optional feature]
  
  Thanks,
  sanjay	
  
> and, given that, I believe the better option is to leave LOM 
> as is and not progress it as a separate effort.
> 
> Thanks,
> Jerry
>