[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
- Prev by Date:
RE:
- Next by Date:
RE:
- Previous by thread:
RE:
- Next by thread:
RE:
- Index(es):