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

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 26 May 2003 13:58:41 +0100

Kireeti,

Once upon a time, we merged 3 technical proposals for DS-TE (one of
which was yours) into a common one. One of the capabilities that was
unique to your proposal was the ability to support overbooking ratios
which are different on a per CT AND per link basis (while the other
methods supported different ratios on different links and different
ratios on a per CT basis, not not on a per CT and per-link basis). Back
then you made a argument that there was some value in allowing this.
This resulted in the addition of the optional Local Overbooking
Multiplier (LOM) method in the DS-TE specs.

A number of people commented that considering the ratio of complexity vs
functionality for this particular capability, we may be better off
issueing the base DS-TE specs without this for now and then add this
capability later or in a separate document. I personnally also favors
such an approach.

What is your take on this?

Cheers

Francois

>> -----Original Message-----
>> From: Jim Boyle [mailto:[email-masked]] 
>> Sent: 24 May 2003 02:31
>> To: Francois Le Faucheur (flefauch)
>> Cc: [email-masked]; Lai, Wai S , ALABS
>> Subject: RE: Reflecting new-MAM/SAM definition in diff-te drafts 
>> 
>> 
<clip>
>> 
>> btw... I also think LOMs are lots of complexity for little gain :)
>> 
>> 
>> 
>> On Tue, 20 May 2003, Francois Le Faucheur (flefauch) wrote:
>> 
>> > Jerry,
>> > 
>> > >> -----Original Message-----
>> > >> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>> > >> Sent: 20 May 2003 17:35
>> > >> To: Dimitry Haskin; Francois Le Faucheur (flefauch)
>> > >> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; Lai, 
>> > >> Wai S (Waisum), ALABS
>> > >> Subject: RE: Reflecting new-MAM/SAM definition in diff-te drafts
>> > >> 
>> > >> 
>> > >> Dimitry, Francois,
>> > >> 
>> > >> > >     o SUM (Reserved (CTc)) <= Max Reservable Bandwidth, 
>> > >> > >         for all "c" in the range 0 <= c <= (MaxCT-1)
>> > >> > > 
>> > >> > > However, this formula is incorrect for DS-TE when per-CT 
>> > >> > > LOM's are used, since the above formula only 
>> reflects the Max 
>> > >> > > Reservable Bandwidth for the entire link, and does not 
>> > >> > > reflect the per-CT local overbooking factors.  So what 
>> > >> > > formula do you suggest when per-CT LOM's are used?
>> > >> 
>> > >> > Wouldn't 'Reserved (CTc)' it the above formula already 
>> > >> accounts for the
>> > >> > overbooking multiplier at CTc?  I don't see how this 
>> > >> formula precludes
>> > >> > per-CT LOM's to be used. Please explain.
>> > >> 
>> > >> Are you then proposing these formulas:
>> > >> 
>> > >> 1. When per-CT LOMs are not used:
>> > >> 
>> > >>      o SUM (Reserved(CTc)) <= Max Reservable Bandwidth, 
>> > >>          for all "c" in the range 0 <= c <= (MaxCT-1)
>> > >> 
>> > >> 2. When per-CT LOMs are used:
>> > >> 
>> > >>      o SUM (Normalized(CTc)) <= Max Reservable Bandwidth, 
>> > >>          for all "c" in the range 0 <= c <= (MaxCT-1)
>> > >> 
>> > >> Is that correct?  Please confirm, and/or give the formulas 
>> > >> you propose.
>> > 
>> > Yes, this is exactly what I propose.
>> > I think this is similar to what you were proposing, only 
>> using "Max Res
>> > Bw" instead of "Max Link Bw". 
>> > 
>> > Sorry I didn't make that very clear before.
>> > 
>> > Cheers
>> > 
>> > FRancois
>> > 
>> > >> 
>> > >> Thanks,
>> > >> Jerry
>> > >> 
>> > 
>> > 
>> > 
>> > 
>> 
>>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 26 May 2003 14:05:15 +0100

All TEWGers,

Thoughts on dropping/keeping LOM in base DS-TE specs?

Thanks

Francois

>> From: Francois Le Faucheur (flefauch) 
>> Sent: 26 May 2003 14:59
>> To: Kireeti Kompella; [email-masked]
>> Subject: Dropping the Local Overbooking Multiplier (LOM) 
>> method from DS-TE specs?
>> 
>> 
>> Kireeti,
>>

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Mon, 26 May 2003 09:32:22 -0400

Francois,

I would also think LOM adds extra complexity for a little gain. So,
you may want to avoid LOM in DS-TE spec for now. Its usefulness
can be evaluated in the future as we gain experience with DS-TE.

Thanks,
Siva

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Mon, 26 May 2003 15:53:13 -0500

Francois,

> Thoughts on dropping/keeping LOM in base DS-TE specs?

I certainly favor dropping LOM if there is only weak justification.  There seems to be ample flexibility in overbooking with both 'Link Size Overbooking' and 'LSP Size Overbooking' options available.

Thanks,
Jerry

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 28 May 2003 11:01:22 -0500

Sanjay, All,

> DSTE-REQ already states that the per-CT overbooking
> is an optional feature and does not require the vendors
> to implement it.
> 
> We already discussed the overbooking/underbooking issues
> quite some time back. I don't think we, should change
> requirement [DSTE-REQ] at this stage (past last call),
> unless there is a real problem or limitation.

The DSTE-REQ say:

" The DS-TE solution MUST also allow overbooking and MUST effectively 
   allow different overbooking ratios to be enforced for different CTs. 
    
   The DS-TE solution SHOULD optionally allow the effective overbooking 
   ratio of a given CT to be tweaked differently in different parts of 
   the network."

This does not exactly *require* LOM.  As we've discussed, by using Link Size Overbooking Multipliers (LSOM) and LSP Size overbooking multipliers (LSPOM), we can achieve some degree of per-CT overbooking that is tweaked differently in different parts of the network.  

For example, by setting
LSOM0 = 1 on link 0,
LSOM1 = 1.5 on link 1,
LSPOM0 = 2 for LSPs on CT0,
LSPOM1 = 1 for LSPs on CT1,
we could overbook CT0 by 2 on link 0 and 3 on link 1 (LSPOM0 * LSOM1 = 2 * 1.5 = 3),
while overbooking CT1 by 1 on link 0 and 1.5 on link 1.

However, for the example Francois gave:
"CT0 is overbooked by factor 2 on link 0 and overbooked by factor 3 on link 1, while CT1 is not overbooked on link0 nor on link1. This could NOT be achieved just by combination of "LSP Size overbooking" and "Link Size Overbooking"; it could only be achieved via the use of the LOM method. But, as being discussed, it is not obvious that the need for this justifies the extra complexity."

I agree that this example requires LOM, but I also agree that the need for this is not obvious.  Can anyone explain why such a capability would be needed?

It is also not obvious that the above flexibility (i.e., need for LOM) is *required* by DSTE-REQ.
 
> If we are trying to change the requirement because the 
> LOM concept is difficult, let's take steps to clarify
> the concept by necessary editorial changes (and examples).

I'm not sure we are trying to change the requirement, however I agree that we need good examples of how/why LOM is absolutely needed to achieve the requirements.

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 28 May 2003 17:31:12 +0100

Hello Sanjaya,

>> From: Choudhury, Sanjaya [mailto:[email-masked]] 
>> Sent: 28 May 2003 16:35
>> To: [email-masked]
>> Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
>> method from DS-TE specs?
>> 
>> 
>> Hi! DSTE-REQ already states that the per-CT overbooking

For the record, the DSTE-REQTS spec does not define requirements for
implementation/vendors. It defines requirements for the ds-te solution.
So, my interpretation of what its text says is just that the DS-TE
solution should try to cope with the corresponding requirement. In other
words, to me, it is identified as an optional feature for the
DSTE-solution (a feature that the DSTE solution should try address, but
may not address).

I really don't want to start a "DSTE-REQTS interpretation" argument. The
only reason I bring that up is to address your point below. ie I don't
think the discussion we're having on taking LOM out of the base specs
would require any change to the DSTE-REQTS document.

Note also that the proposal is just to take it out of the base spec, not
necessarily to drop it altogether (eg it could be documented separately
- perhaps as an experimetal RFC, like the BC Models). 

>> LOM concept is difficult, 

I don't think the concern is that the LOM solution itself is too
complicated for the given requirement or not understood. To me it's more
a question of saying: now that we understand the ratio between the
functional benefit of the particular optional requirement and the
complexity associated with it, do we actually think it is worth keeping
in the base spec?

Now, you may feel that indeed it is worth and that LOM should stay in
base spec. But I wanted to be sure we were all looking at the same
question, and you're not feeling LOM should stay in simply because you
felt it is somehow mandated by the DSTE-REQTS.

Thanks

Francois

>>let's take steps to clarify
>> sanjay
>> > From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
>> > Sent: Monday, May 26, 2003 9:05 AM
>> > To: [email-masked]
>> > Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
>> > method from
>> > DS-TE specs?
>> > 
>> > 
>> > All TEWGers,
>> >