[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Dropping the Local Overbooking Multiplier (LOM) method from DS-TE specs?
Hello Sanjaya,
>> -----Original Message-----
>> From: Choudhury, Sanjaya [mailto:Sanjaya.Choudhury@Marconi.com]
>> Sent: 03 June 2003 16:10
>> To: te-wg@ops.ietf.org
>> Subject: RE: Dropping the Local Overbooking Multiplier (LOM)
>> method from DS-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
>>
Understood.
>> 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.
Noted.
Unless the people who expressed first preference for taking LOM out of
base spec get convinced to change their mind soon, it seems likely we
won't all agree on our first preference. So this seems to me like a
likely avenue.
>>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
>>
I agree that neither of these issues individually is unsurmountable.
But the real issue to consider seems rather that the ratio between the
extra functionality and the extra complexity is very high (not so much
because the extra complexity is high but mainly because the extra
functionality appears very low).
Another way to consider this question is the following.
A general principle we've followed for the dste-proto is to only specify
protocol extensions necessary in order to carry all of, but no more
than, the mechanisms that exist in regular TE and make them work in the
presence of multiple CTs. I very much support that principle : make it
only as complicated as necessary to support multiple CTs, but no more.
As you've mentioned below, this is precisely the case for Link Size
Overbooking and LSP Size Overbooking. We only did what we had to do to
make these concepts from regular TE work with multiple CTs.
The one exception is LOM which is more like doing something beyond what
already exists in regular TE. Now all principles can be broken, but I
would expect a stronger case in terms of requirement to justify doing
so.
I won't comment on your discussion of the individual issues below
because, as I said, the more relevant question is their combined
trade-off. I will just mention one thing relating to your issue 5 (which
I think is similar to Dimitry's point): of course we want to be able to
do per-CT overbooking. But this is in no way a justification for LOM.
You can do per-CT overbooking perfectly well without LOM. Again, the
only thing you cannot do is enforce an overbooking ratio which is
differnet on a per link and per CT basis. But you can certainly have
different overbooking ratios per CT and simultaneously have different
overbooking ratios per link.
The meaningful formation here would be to hear if Service Providers feel
that being able to "simultaneously enforce different overbooking ratios
per CT and different overbooking ratios per link" may not be sufficient
for their environment and that different overbooking ratios per-CT AND
per-link are required.
Thanks again for your thoughts.
Francois
>> 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
>> > >>
>> >
>>
>>