RE: I-D ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt

[neil.2.harrison@bt.com]

Jerry,

What assumptions (if any) are you making about a given
application/customer's ability to class-hop?  That is, potential to change
class types (maybe at will?) based on current/past QoS experience and
charging regime.

regards, Neil

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALASO [mailto:gash@att.com]
> Sent: 17 November 2002 00:00
> To: Francois Le Faucheur (flefauch)
> Cc: Ash, Gerald R (Jerry), ALASO; te-wg
> Subject: RE: I-D
> ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt
> 
> 
> Francois,
> 
> Responses to you further questions below.
> 
> Thanks,
> Jerry
> 
> > -----Original Message-----
> > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
> > Sent: Tuesday, November 12, 2002 11:38 AM
> > To: Ash, Gerald R (Jerry), ALASO
> > Cc: te-wg@ops.ietf.org
> > Subject: FW: I-D 
> ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-00.txt
> > 
> > A few more questions on the example below:
> > 
> > 1) as described below, it looks to me like MAR would cope well with
> > "overload" situations in situations where all CTs are gradually
> > increasing their load at the same time so they start 
> "contending" before
> > one CT has had a chance to hog a lot of bandwidth. 
> > But it is not clear how to me MAR would cope with 
> situations where one
> > CT gets greedy before the other CTs get a chance to contend: for
> > example, if we assume that CT0 only has reserved 5 and CT1 only has
> > reserved 5, is there anything that would prevent CT2 from 
> reserving up
> > to 80?
> 
> It could in the example.  However, only CT1 and CT0 could 
> then increase their bandwidth (not CT2).  As CT1 and CT0 
> increase, the available bandwidth goes below the reserved 
> bandwidth threshold (RBW), so CT2 can no longer increase its 
> bandwidth, only decrease.  Furthermore, as flows/LSPs leave 
> CT2, freeing up available bandwidth, then CT1 and CT0 can 
> further increase, but CT0 can still only decrease.  RBW is 
> set such that all CTs have a high probability of getting 
> their allocated bandwidth (BWalloc).  CTs can go above their 
> BWalloc when their is available bandwidth, however the BW 
> reservation mechanism prevents them from hogging and also 
> retaining the bandwidth above their BWalloc.
>  
> > 2) as described below, MAR seemed to target some minimum per-CT
> > bandwidth apportionment via BWalloc[i] in case of 
> contention, but does
> > not seem to be able to enforce a hard "per-CT" maximum 
> reservation in
> > the absence of contention. 
> > For example, let's say SP wants to first establish all the 
> Voice TE-LSPs
> > and want to limit those to 40% of link capacity for some voice
> > engineering reason (say the Premium Data LSPs and 
> Best-Effort LSPs will
> > be established after the Voice LSPs).
> > Could you use MAR to ensure CT2 Voice LSPs would be limited 
> to 40% even
> > when they are established before any CT1 and CT0 LSPs?
> > Or are you assuming that load across all CTs is normally increasing
> > simultaneously?
> 
> No assumption is made that CTs increase or decrease 
> simultaneously.  As discussed above and in the draft, no CT 
> can get much above its BWalloc when there is contention.  If 
> there is no contention, then I'm not sure why you need to 
> limit CTs to a maximum bandwidth, why not let a CT use the 
> available bandwidth if there is demand (as described above, 
> it cannot hold the bandwidth if contention arises later)?  A 
> maximum reservation per CT could be added to MAR, of course, 
> but it makes the BC model more complicated and it's unclear 
> to me why it's needed.
>  
> > 3) In the case where we want to provide all necessary 
> information to a
> > Head-end to be able to perform optimization in case of multiple LSP
> > establishment, what would be the parameters that would need to be
> > signaled in IGP (BWalloc, RBW,...?)?
> 
> I think only available bandwidth (ILBW in the draft) needs to 
> be signaled.
>  
> > Thanks
> > 
> > Francois
> > 
> >> We have 3 CTs: CT0, CT1, CT2, all with 'normal' priority.
> >> We have a particular link with capacity = 100. 
> >> MAR allocates CT bandwidth for the normal traffic loads, and 
> >> in this example the BWalloc values on the given link are 
> as follows:
> >> 
> >> BWalloc for CT0 = BWalloc0 = 30
> >> BWalloc for CT1 = BWalloc1 = 20
> >> BWalloc for CT2 = BWalloc2 = 20
> >>  
> >> This leaves 100 - 70 = 30 units of spare bandwidth on the 
> >> link under normal loading.  With MAR, any of the CTs is 
> >> allowed to exceed its BWalloc as long a there is at least 
> >> RBWk (reserved bandwidth on the link) units of spare 
> >> bandwidth remaining.
> >> 
> >> Let's say RBW = 10.  So under overload, if 
> >> 
> >> CT0 has taken 50 units of bandwidth (bandwidth-in-progress 
> >> for CT0 = BWIP0 = 50),
> >> CT1 has taken 30 units of bandwidth (bandwidth-in-progress 
> >> for CT1 = BWIP1 = 30),
> >> CT2 has taken 10 units of bandwidth (bandwidth-in-progress 
> >> for CT2 = BWIP2 = 10),
> >> 
> >> Therefore, for this loading,
> >> Idle link bandwidth (ILBW) = 100 - 50 - 30 - 10 = 10
> >> 
> >> Let's say a flow arrives for CT0 needing 5 units of 
> >> bandwidth (i.e., DBW = 5).  We need to decide based on Table 
> >> 2 and Table 1 whether to admit this flow or not.
> >> 
> >> The link load state is determined from Table 2:
> >> 
> >> Since ILBW - RBW < DBW (i.e., 10 - 10 < 5), Table 2 says the 
> >> link is in the RBW (reserved bandwidth) state.
> >> 
> >> The allowed load state is determined from Table 1 (the 
> >> allowed load state is the minimum level of bandwidth that 
> >> must be available on a link to admit the flow):
> >> 
> >> Since for CT0 (normal priority) BWalloc0 < BWIP0 (30 < 50), 
> >> Table 2 says the allowed load state is ABW (available bandwidth).
> >> 
> >> Hence since the link has less bandwidth (RBW state) than the 
> >> allowed load state level of bandwidth required to admit the 
> >> flow (ABW), the flow is rejected/blocked.
> >> 
> >> Now let's say a flow arrives for CT2 needing 5 units of 
> >> bandwidth (i.e., DBW = 5).  We need to decide based on Table 
> >> 2 and Table 1 whether to admit this flow or not.
> >> 
> >> The link load state is determined from Table 2:
> >> 
> >> Since ILBW - RBW < DBW (i.e., 10 - 10 < 5), Table 2 says the 
> >> link is in the RBW (reserved bandwidth) state.
> >> 
> >> The allowed load state is determined from Table 1 (the 
> >> allowed load state is the minimum level of bandwidth that 
> >> must be available on a link to admit the flow):
> >> 
> >> Since for CT2 (normal priority) BWIP2 < BWalloc2 (10 < 20), 
> >> Table 2 says the allowed load state is RBW (reserved bandwidth).
> >> 
> >> Hence since the link has sufficient bandwidth (RBW state) 
> >> compared to the allowed load state level of bandwidth 
> >> required to admit the flow (also RBW), the flow is admitted.
> >> 
> >> Hence, in the above example, in the current state of the 
> >> link and the current CT loading, CT0 and CT1 can no longer 
> >> increase their bandwidth on the link, since they are above 
> >> their BWalloc values and there is only RBW=10 units of spare 
> >> bandwidth left on the link.  
> >> 
> >> But CT2 can take the additional bandwidth (up to 10 units) 
> >> if the demand arrives, since it is below its BWalloc value.
>