[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue-5: RE: Dropping the Local Overbooking Multiplier (LOM) method from D S-TE specs?
Hi Dimitry!,
Here is what we seem to agree on: A per-CT overbooking knob
is useful for the administrators.
Now on to your second point: per-CT overbooking can be done
without overbooking. In my personal opinion, you might have
made few wrong assumptions:
1. Your example requires the preemption to be enabled
in the domain; which may not be true.
=>LOM gives user explicit control overbooking at a
per-CT level, without the need to preemption.
2. You indicated "However without LOM amount of
reservations in one CT may not accurately effect
reservable bandwidths in other CTs of the same link"
=>Don't you think this a problem? Head-end LSR computed
the path based on the advertised BWs per-CT [which is
is the foundation of DSTE], will now compute a wrong
path.
2. For a moment let is assume that preemption *is*
deployed in the domain. Can you explain me how I
will achieve the following [please be specific in
what the user will need to do and the BC model in
use]:
case-1: want to overbook data-traffic without
overbooking voice traffic.
case-2: Want to overbook the voice traffic by
10%, but want to overbook data traffic by 40%
case-3: want to overbook gold-traffic by 10%,
overbook silver-traffic by 15%, overbook
normal-traffic by 20%
3. Can all of the above be achieved without the
use pre-emption?
Thanks,
sanjay
> -----Original Message-----
> From: Dimitry Haskin [mailto:dhaskin@axiowave.com]
> Sent: Tuesday, June 03, 2003 2:34 PM
> To: 'Choudhury, Sanjaya'; te-wg@ops.ietf.org
> Subject: RE: Dropping the Local Overbooking Multiplier (LOM)
> method from
> D S-TE specs?
>
>
> 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
> > > >>
> > >
> >
>