[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Preemption with MAM RE:
Waisum,
Let me try one more time.
Adding some implicit bandwidth constraint (or whatever you want to call that) is not a clarification to MAM. It is a different model.
- Where MAM currently has a Maximum Number of Bandwidth Constraints of 8 (ie one per CT), this model would have a maximum of 9 BCs (ie one per CT plus one aggregate). BTW, this in turn, would require change to the ISIS/OSPF extensions which can only advertise 8 Bandwidth Constraints.
- You would have to add a completely new rule to the definition like:
SUM (Reserved (CTb) ) <= BC9, ( b in the range 0 <= b <= (MaxCT - 1))
- All the CAC formulas would be different
Francois
>> -----Original Message-----
>> From: Lai, Wai S (Waisum), ALABS [mailto:wlai@att.com]
>> Sent: 25 March 2003 23:10
>> To: Francois Le Faucheur (flefauch); Geunhyung Kim; Dimitry
>> Haskin; Te-Wg
>> Subject: RE: Preemption with MAM RE:
>>
>>
>> Francois,
>> Preemption across CTs in MAM was presented to the TEWG, at
>> least as early as June 2002, when the 00 version of
>> <draft-wlai-tewg-bcmodel> was submitted. Dimitry's posting
>> also confirmed this mode of operation.
>> The MAM definition simply says that Reserved (CTb) <= BCb,
>> i.e., the reserved bandwidth of a CT is *either less than or
>> equal to* the bandwidth constraint for the CT. Thus, when
>> contention resulting in preemption across CTs occurs, the
>> reserved bandwidth of a CT can/may be less than the
>> bandwidth constraint for the CT, depending on the relative
>> preemption priorities of the different CTs involved.
>> We can add this clarification to the MAM spec.
>> Thanks, Wai Sum
>>
>> -----Original Message-----
>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
>> Sent: Monday, March 24, 2003 5:31 PM
>> To: Lai, Wai S (Waisum), ALABS; Geunhyung Kim; Te-Wg
>> Subject: Preemption with MAM RE:
>>
>>
>> Waisum,
>>
>> >> -----Original Message-----
>> >> From: Lai, Wai S (Waisum), ALABS [mailto:wlai@att.com]
>> >> Sent: 24 March 2003 19:11
>> >> To: Geunhyung Kim; Te-Wg
>> >> Subject: RE:
>> >>
>> >>
>> >> Geunhyung,
>> >> Thanks for your query. If preemption is disabled, then of
>> >> course there will be no preemption, whether within a given
>> >> CT, or across CTs, regardless of any BC model used.
>> >> However, if preemption is enabled, then there can certainly
>> >> be preemption across CTs in the MAM model.
>> >> Francois, the DS-TE Requirements document does not place
>> >> any restrictions on preemption in MAM.
>>
>> That is correct.
>>
>> >> As stated in Section 4.4 of the DS-TE Requirements
>> >> document, "if LSP1 contends with LSP2 for resources, LSP1
>> >> may preempt LSP2 if LSP1 has a higher set-up preemption
>> >> priority (i.e. lower numerical priority value) than LSP2's
>> >> holding preemption priority regardless of LSP1's OA/CT and
>> >> LSP2's OA/CT."
>>
>> That statement is correct. But note that it starts with "
>> *IF* LSP1 contends with LSP2". With MAM as it has been
>> defined for a long time in the TEWG, LSP1 can only be
>> contending with LSP2 if they are in the same CT. If they are
>> in different CT, they are each subject to independent
>> bandwidth constraints and therefore simply can not be in a
>> situation where they contend. So while preemption across CTs
>> is not "forbidden", it is simply not applicable.
>>
>> >>Different methods can be used to meet this
>> >> requirement. The MAM model takes care of it simply by an
>> >> implicit aggregate constraint.
>>
>> There is no such thing as "implicit constraint". There are
>> Bandwidth Constraints which are all pretty explicit. The
>> reason we've written down definitions for these models is so
>> that everybody knows what are the bandwidth constraints.
>>
>> MAM definition says:
>> "
>> o Maximum Number of Bandwidth Constraints
>> (MaxBC)= Maximum
>> Number of Class-Types (MaxCT) = 8
>> o for each value of b in the range 0 <= b <=
>> (MaxCT - 1):
>> Reserved (CTb) <= BCb,
>> "
>> MAM involves just one Bandwidth Constraint per CT, and those
>> are independent.
>>
>> It may be that another model which has independent bandwidth
>> constraint + aggregate constraint (this would basically be a
>> hybrid between MAM and RDM) is a reasonable idea; but this
>> is not MAM as it is currently defined.
>>
>> Cheers
>>
>> Francois
>>
>>
>> >> Other models may use an
>> >> explicit constraint.
>> >> Geunhyung, your example below reflects the correct
>> >> operation in MAM with preemption across CTs (assuming that
>> >> CT0 has the highest set-up preemption priority, and CT3 is a
>> >> typo of CT2).
>> >> Thanks, Wai Sum
>> >>
>> >> -----Original Message-----
>> >> From: Geunhyung Kim [mailto:geunkim@postech.ac.kr]
>> >> Sent: Wednesday, March 19, 2003 11:57 PM
>> >> To: Te-Wg
>> >> Subject: RE:
>> >>
>> >>
>> >> Hi all,
>> >>
>> >> At first, I would like to ask one question.
>> >> Is there preemption across CTs in the MAM model ?
>> >>
>> >> If there is preemption across CTs, there is aggregate limit
>> >> implicitly in MAM with preemption.
>> >>
>> >> In the Faucheur's example (link of 100 and BC0=50, BC1=50,
>> >> BC2=50), when the link is congested, there are only CT0 and
>> >> CT1 traffics.
>> >>
>> >> in the first phase, there is only CT2 traffic with 50.
>> >> after that, there are requests of CT0 traffic demand with 40
>> >> and CT1 traffic demand 30.
>> >> if these requests are accepted, the link capacity is divided
>> >> into CT0(40), CT1(30), CT3(30), because there is preemption
>> >> across CTs.
>> >>
>> >> However, if there is not preemption across CTs, there is
>> >> aggregate limit in MAM with preepmtion(neither explicit
>> nor implicit)
>> >>
>> >> Regards,
>> >>
>> >> Geunhyung
>> >>
>> >> None of us is as smart as all of us
>> >> ==========================================
>> >> Geunhyung Kim
>> >>
>> >> E-mail: geunkim@postech.edu
>> >>
>> >> Tel: +82-54-279-5655
>> >> Fax: +82-54-279-5699
>> >>
>> >> Networking & Distributed Systems Lab.
>> >> CSE
>> >> POSTECH
>> >> ===========================================
>> >>
>> >> -----Original Message-----
>> >> From: owner-te-wg@ops.ietf.org
>> >> [mailto:owner-te-wg@ops.ietf.org]On Behalf Of Francois Le
>> >> Faucheur (flefauch)
>> >> Sent: Thursday, March 20, 2003 12:32 PM
>> >> To: Lai, Wai S (Waisum), ALABS; LE ROUX Jean-Louis FTRD/DAC/LAN
>> >> Cc: te-wg@ops.ietf.org
>> >> Subject: RE:
>> >>
>> >>
>> >>
>> >> Waisum,
>> >> As Jean-Louis said, there is no aggregate limit with MAM
>> >> (neither explicit nor implicit).
>> >> If you have a link of 100 and BC0=50, BC1=50 and BC2=50,
>> >> then you may very well endup with a load of up to 150 across
>> >> the three CTs.
>> >> Hence, with MAM:
>> >> - you may have preemption within a CT (ie an LSP of CTx
>> >> may need to preempt another LSP of same CTx)
>> >> - you will not have preemption across CTs (ie an LSP of
>> >> CTx will not preempt another LSP of Cty, since those don't
>> >> contend for bandwidth).
>> >> Cheers
>> >> Francois
>> >>
>> >>
>> >> >> -----Original Message-----
>> >> >> From: Lai, Wai S (Waisum), ALABS [mailto:wlai@att.com]
>> >> >> Sent: 20 March 2003 04:13
>> >> >> To: LE ROUX Jean-Louis FTRD/DAC/LAN
>> >> >> Cc: te-wg@ops.ietf.org
>> >> >> Subject: RE:
>> >> >>
>> >> >>
>> >> >> JL,
>> >> >> Do you mean that there is no *explicit* constraint for
>> >> >> the aggregate bandwidth reserved from different classes? As
>> >> >> I described in my previous reply below, when the constraints
>> >> >> sum up to link capacity, there is "total isolation" with no
>> >> >> preemption among classes (which is not necessary of course).
>> >> >> When this is not the case, then the link capacity will act
>> >> >> implicitly as the aggregate constraint. This is a natural
>> >> >> aggregate constraint (or an appropriately scaled aggregate
>> >> >> constraint in the case of overbooking) that does not need to
>> >> >> be explicitly spelled out, right? When this aggregate
>> >> >> constraint is to be exceeded, then preemption among classes
>> >> >> will act in accordance with the definition, which says that
>> >> >> Reserved (CTb) <= BCb, i.e., the reserved bandwidth of a
>> >> >> class is *either less than or equal to* the bandwidth
>> >> >> constraint for the class, depending on the relative
>> >> >> preemption priorities of the different classes involved.
>> >> >> Thanks, Wai Sum
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: LE ROUX Jean-Louis FTRD/DAC/LAN
>> >> >> [mailto:jeanlouis.leroux@rd.francetelecom.com]
>> >> >> Sent: Wednesday, March 19, 2003 8:25 PM
>> >> >> To: Lai, Wai S (Waisum), ALABS
>> >> >> Cc: te-wg@ops.ietf.org
>> >> >> Subject: RE:
>> >> >>
>> >> >>
>> >> >> Wai Sum,
>> >> >>
>> >> >> Preemption among classes can definitively not occur with
>> >> >> current MAM defintion, whatever the preemtion priorities,
>> >> >> because there is no constraint for the aggregate bandwidth
>> >> >> reserved from different classes
>> >> >>
>> >> >> If you define BC2= 5M, BC1= 7M, BC0= 15M, then you can
>> >> >> reserve simultaneously 5M of CT2 LSPs and 7M of CT1 LSP and
>> >> >> 15M of CT0 LSPs.
>> >> >>
>> >> >> To allow preemtion between classes you need constraint on
>> >> >> the cumulated bandwidth reserved from diffrerent classes,
>> >> >> which does not exist in MAM.
>> >> >>
>> >> >>
>> >> >> Regards
>> >> >>
>> >> >> JL
>> >> >>
>> >> >> -----Message d'origine-----
>> >> >> De : Lai, Wai S (Waisum), ALABS [mailto:wlai@att.com]
>> >> >> Envoyé : mercredi 19 mars 2003 02:29
>> >> >> À : LE ROUX Jean-Louis FTRD/DAC/LAN
>> >> >> Cc : te-wg@ops.ietf.org
>> >> >> Objet : RE:
>> >> >>
>> >> >>
>> >> >> Jean-Louis,
>> >> >> Associated with each class-type (or simply referred to as
>> >> >> a class in my draft, as stated in the 2nd paragraph of
>> >> >> Section A.3) there is a preemption priority, which together
>> >> >> form a TE-class. This enables preemption among class-types.
>> >> >> "Total isolation between classes" is provided in MAM only
>> >> >> when the bandwidth constraints for different classes add up
>> >> >> exactly to the link capacity. When this is not the case
>> >> >> (e.g., with overbooking), there will be interference among
>> >> >> classes. As shown in my draft, the degree of this
>> >> >> interference depends on the degree of bandwidth sharing,
>> >> >> whether preemption is used or not, and the relative
>> >> >> preemptin priority. This is a general property for any BC
>> >> >> models: the higher the degree of sharing, the less robust
>> >> >> the service isolation.
>> >> >> My view of overbooking is concerned with dimensioning a
>> >> >> link to carry the different classes of traffic offered while
>> >> >> meeting service objectives. I have not explicitly used a
>> >> >> multiplier to scale the bandwidth of might appear to be
>> >> >> available and advertised, if that's what you are referring
>> >> >> to. But I think I have done that implicitly, so as to show
>> >> >> the performance impacts, and the need for a judicious choice
>> >> >> of overbooking multipliers. Thus, my example of twice the
>> >> >> normal traffic (while discussed in the context of overload)
>> >> >> is effectively scaling with a factor of 2.
>> >> >> Thanks, Wai Sum
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: LE ROUX Jean-Louis FTRD/DAC/LAN
>> >> >> >> [mailto:jeanlouis.leroux@rd.francetelecom.com]
>> >> >> Sent: Monday,
>> >> >>
>> >> >> March 17, 2003 8:59 PM
>> >> >> To: Lai, Wai S (Waisum), ALABS
>> >> >> Cc: te-wg@ops.ietf.org
>> >> >> Subject:
>> >> >>
>> >> >>
>> >> >> Hi Wai Sum and all
>> >> >> I have a question regarding draft-wlai-tewg-bcmodel-01
>> >> >> Section A.3 :
>> >> >> "Preemption is enabled so that, when necessary, class 1 can
>> >> >> preempt class 2...."
>> >> >> How can you apply this to MAM ??
>> >> >> If I refer to 3.0 definition,MAM ensures total isolation
>> >> >> between classes, preemption can occurs only inside a class,
>> >> >> but not between classes
>> >> >>
>> >> >>
>> >> >> "Overbooking is allowed as it is to be described below..."
>> >> >> How do you define overbooking here ?
>> >> >> Overbooking is definitively not allowed in your RDM
>> >> example (BC0=15)
>> >> >> Regards
>> >> >> JL
>> >> >>
>> >> >>
>> >>
>> >>
>>