Traffic Management for the Available Bit Rate (ABR) Service in ...
Traffic Management for the Available Bit Rate (ABR) Service in ... Traffic Management for the Available Bit Rate (ABR) Service in ...
7.1.1 Issues in Use-It-or-Lose-It When some VCs' present bursty or source-bottlenecked tra c, the network may experience underload even after rate allocation. It then allocates higher rates to all VCs without rst taking back the unused allocations. As a result, the underloading sources retain their high allocations without using them. When these sources sud- denly use their allocations, they overload the network.This problem is called \ACR Retention." A related problem is \ACR Promotion" where a source intentionally refrains from using its allocation aiming to get higher allocations in later cycles. The e ect of ACR Retention/Promotion is shown in Figure 7.1. In the gure, before time t 0 the source rate is much smaller than its ACR allocation. The ACR allocation remains constant. At time t 0, the source rate rises to ACR and the network queues correspondingly rise. These problems were rst identi ed by Barnhart [7]. Figure 7.1: E ect of ACR Retention/Promotion A solution to this problem is to detect an idle or source-bottlenecked source and reduce its rate allocation before it can overload the network. But this has an impor- tant side e ect on bursty sources. If the rates are reduced after every idle period and the active periods are short, the aggregate throughput experienced by the source is 225
low. This tradeo was discovered and studied carefully in the ATM Forum. The solu- tions proposed are popularly known as the Use-It-or-Lose-It (UILI) policies, referring to the fact that the source's ACR is reduced (lost) if it is not used. 7.1.2 Early UILI Proposals The UILI function can be implemented at the SES (source-based) or at the switch (switch-based) or at both places. The early UILI proposals were all source-based. In these proposals, the test for ACR retention is done when an RM cell is being sent by the source. If ACR retention is detected, the source's ACR is immediately reduced using a rate reduction algorithm. Further, to prevent network feedback from overriding the ACR reduction, some proposals ignore the next feedback from the switch (if the feedback requests a rate increase). Over the February, April, May and June 1995 meetings of the ATM Forum, several UILI proposals were considered. The proposals di er in how the ACR retention is detected (additive ormultiplicative metric), andinthealgorithm used to reduce ACR. In February 1995, Barnhart proposed a formula which reduced ACR as a function of the time since the last RM cell was sent or rate decrease was last done: ACRn = ACRo(1 ; T ACRo/RDF) ACRn is the new ACR and ACRo is the old ACR. The time `T' in the formula is the time which has transpired since the last backward RM cell was received or since the last ACR decrease. RDF is the rate decrease factor which is normally used to calculate the new rate for single-bit feedback. However, it is reused in the reduction formula to avoid choosing a new parameter. ACR retention is detected when the 226
- Page 201 and 202: 6.16 ERICA+: Maintain a \Pocket" of
- Page 203 and 204: hence, introduces a new parameter,
- Page 205 and 206: Figure 6.4: Linear functions for ER
- Page 207 and 208: and Figure 6.6: The queue control f
- Page 209 and 210: small averaging intervals. If the a
- Page 211 and 212: The maximum value of T 0 also depen
- Page 213 and 214: 6.22 Performance Evaluation of the
- Page 215 and 216: espectively. The target delay T 0 i
- Page 217 and 218: 6.22.4 Fairness Figure 6.9: Parking
- Page 219 and 220: st link, VC 15 is limited to a thro
- Page 221 and 222: From the gures, it is clear that ER
- Page 223 and 224: counts the bursty source as active
- Page 225 and 226: 6.23 Summary of the ERICA and ERICA
- Page 227 and 228: (a) Transmitted Cell Rate (c) Link
- Page 229 and 230: (a) Transmitted Cell Rate (c) Link
- Page 231 and 232: (a) Transmitted Cell Rate (c) Link
- Page 233 and 234: (a) Transmitted Cell Rate (basic ER
- Page 235 and 236: (a) Transmitted Cell Rate (basic ER
- Page 237 and 238: (a) Transmitted Cell Rate (c) Link
- Page 239 and 240: (a) Transmitted Cell Rate (c) Link
- Page 241 and 242: (a) Transmitted Cell Rate (c) Link
- Page 243 and 244: (a) Transmitted Cell Rate (c) Link
- Page 245 and 246: (a) Transmitted Cell Rate (c) Link
- Page 247 and 248: (a) Transmitted Cell Rate (c) Link
- Page 249 and 250: (a) Transmitted Cell Rate (basic ER
- Page 251: RM cells. In this chapter, we devot
- Page 255 and 256: in the speci cation. b) ACR shall n
- Page 257 and 258: 7.1.6 December 1995 Proposals There
- Page 259 and 260: Figure 7.2: Multiplicative vsAdditi
- Page 261 and 262: is never triggered. However, the PR
- Page 263 and 264: simulation results of bursty source
- Page 265 and 266: 1. The time-based proposal also ind
- Page 267 and 268: The switch maintains a local alloca
- Page 269 and 270: PNI = f0, 1g : f1 ) No rule 5b, 0 )
- Page 271 and 272: after reaching the goal. The time-b
- Page 273 and 274: Figure 7.8: Closed-Loop Bursty Tra
- Page 275 and 276: The algorithm measures the load and
- Page 277 and 278: Medium Bursts Medium bursts are exp
- Page 279 and 280: count-based technique may be insu c
- Page 281 and 282: Figure 7.13: An event trace illustr
- Page 283 and 284: CHAPTER 8 SUPPORTING INTERNET APPLI
- Page 285 and 286: u ering which does not depend upon
- Page 287 and 288: 4 make it to the destination are ar
- Page 289 and 290: Figure 8.3: At the ATM layer, the T
- Page 291 and 292: issues and e ect of bursty applicat
- Page 293 and 294: from the loss and they trigger the
- Page 295 and 296: 8.8 Performance Metrics We measure
- Page 297 and 298: the performance is fair. Also, the
- Page 299 and 300: Figure 8.7(b) shows the rates (ACRs
- Page 301 and 302: Window Size in bytes vfive-tcp/opti
7.1.1 Issues <strong>in</strong> Use-It-or-Lose-It<br />
When some VCs' present bursty or source-bottlenecked tra c, <strong>the</strong> network may<br />
experience underload even after rate allocation. It <strong>the</strong>n allocates higher rates to all<br />
VCs without rst tak<strong>in</strong>g back <strong>the</strong> unused allocations. As a result, <strong>the</strong> underload<strong>in</strong>g<br />
sources reta<strong>in</strong> <strong>the</strong>ir high allocations without us<strong>in</strong>g <strong>the</strong>m. When <strong>the</strong>se sources sud-<br />
denly use <strong>the</strong>ir allocations, <strong>the</strong>y overload <strong>the</strong> network.This problem is called \ACR<br />
Retention." A related problem is \ACR Promotion" where a source <strong>in</strong>tentionally<br />
refra<strong>in</strong>s from us<strong>in</strong>g its allocation aim<strong>in</strong>g to get higher allocations <strong>in</strong> later cycles. The<br />
e ect of ACR Retention/Promotion is shown <strong>in</strong> Figure 7.1. In <strong>the</strong> gure, be<strong>for</strong>e time<br />
t 0 <strong>the</strong> source rate is much smaller than its ACR allocation. The ACR allocation<br />
rema<strong>in</strong>s constant. At time t 0, <strong>the</strong> source rate rises to ACR and <strong>the</strong> network queues<br />
correspond<strong>in</strong>gly rise. These problems were rst identi ed by Barnhart [7].<br />
Figure 7.1: E ect of ACR Retention/Promotion<br />
A solution to this problem is to detect an idle or source-bottlenecked source and<br />
reduce its rate allocation be<strong>for</strong>e it can overload <strong>the</strong> network. But this has an impor-<br />
tant side e ect on bursty sources. If <strong>the</strong> rates are reduced after every idle period and<br />
<strong>the</strong> active periods are short, <strong>the</strong> aggregate throughput experienced by <strong>the</strong> source is<br />
225
Change language