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

Hello Sanjaya,

>> > For the record, the DSTE-REQTS spec does not define 
>> requirements for
>> > implementation/vendors. It defines requirements for the ds-te 
>> > solution.
>> 
>> 	Missed "DSTE-PROTO" before the "and" in the original e-mail.
>> 	Anyway, DSTE-REQ calls out for the solution draft to optionally
>> 	support ability to tweak the overbooking factor of a CT in 
>> 	different parts of the network. DSTE-PROTO already provides a 
>> 	solution for this (as an optional feature). 
>> 
>> 	I am not against moving the LOM feature into its own draft, 

Noted.

>>but
>> 	I fail to understand: What good does it do, to remove the 
>> 	(already optional) LOM feature from the base spec? 
>> 

To me the main benefits are:
	- make the DS-TE core specifications simpler (to read,
implement, deploy) and thus maximise its chances of sucessful deployment
	- would allow us to progress LOM in the "Experimental" track,
which I think matches better the TEWG feel (ie something that may or may
not be useful and where experience will tell).

>> 	If we move the LOM into its own draft, do the BC model drafts 
>> 	still need to ensure that the model still works when LOM is in
>> 	use? Or do we need more drafts to extend the BC model drafts?
>> 

My proposal would be that the single LOM draft discusses (i) the concept
of LOMs, (ii) the BC-model-independent aspects of LOMs (eg. IGP
extensions, applying constraints to Normalised vs Reserved) and (iii)
the BC-model-specific aspects (eg take the CAC/Unreserved-Bw formuals
that are currently in -russian and -mam ). So I think a single draft
could cover all the aspects of LOM. Again, that is a good property o
LOM, it has been defined as a pure "increment" of LSP/Size overbooking
and is thus very easy to keep in or out.

>> 	An aside: DSTE basically provides a per-CT knob on the LSRs. 
>> 	And a per CT overbooking knob, might allow a provider 
>> to overbook
>> 	the data traffic on a link, without overbooking the real-time
>> 	traffic (on the same link) at the same level.
>> 

Yes, as discussed, there is quite a lot we can do without LOM.

Thanks

Francois

>> 	Thanks,
>> 	sanjay
>> 
>> > 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). 
>> > 
>> > >> 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.
>> > >> 
>> > >> If we are trying to change the requirement because the 
>> > >> 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
>> > >> the concept by necessary editorial changes (and examples).
>> > >> 
>> > >> Thanks,
>> > >> sanjay
>> > >> 
>> > >> > -----Original Message-----
>> > >> > From: Francois Le Faucheur (flefauch) 
>> [mailto:[email protected]]
>> > >> > Sent: Monday, May 26, 2003 9:05 AM
>> > >> > To: [email protected]
>> > >> > Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
>> > >> > method from
>> > >> > DS-TE specs?
>> > >> > 
>> > >> > 
>> > >> > All TEWGers,
>> > >> > 
>> > >> > Thoughts on dropping/keeping LOM in base DS-TE specs?
>> > >> > 
>> > >> > Thanks
>> > >> > 
>> > >> > Francois
>> > >> > 
>> > >> > >> -----Original Message-----
>> > >> > >> From: Francois Le Faucheur (flefauch) 
>> > >> > >> Sent: 26 May 2003 14:59
>> > >> > >> To: Kireeti Kompella; [email protected]
>> > >> > >> Subject: Dropping the Local Overbooking Multiplier (LOM) 
>> > >> > >> method from DS-TE specs?
>> > >> > >> 
>> > >> > >> 
>> > >> > >> 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 protected]] 
>> > >> > >> >> Sent: 24 May 2003 02:31
>> > >> > >> >> To: Francois Le Faucheur (flefauch)
>> > >> > >> >> Cc: [email protected]; 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 protected]] 
>> > >> > >> >> > >> Sent: 20 May 2003 17:35
>> > >> > >> >> > >> To: Dimitry Haskin; Francois Le Faucheur (flefauch)
>> > >> > >> >> > >> Cc: Ash, Gerald R (Jerry), ALABS; 
>> > >> [email protected]; 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
>> > >> > >> >> > >> 
>> > >> > >> >> > 
>> > >> > >> >> > 
>> > >> > >> >> > 
>> > >> > >> >> > 
>> > >> > >> >> 
>> > >> > >> >> 
>> > >> > >> 
>> > >> > >> 
>> > >> > 
>> > >> 
>> > >> 
>> > 
>> 
>>