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 ...
CHAPTER 7 SOURCE RULE DESIGN FOR THE ABR SERVICE In the earlier chapters of this dissertation we have examined switch scheme design in detail, including our proposals (OSU, ERICA and ERICA+). In this chapter, we will examine the design of source rules in the ATM Tra c Management framework. The source rules, as described in Chapter 2, determine the scheduling of data and bidirectional RM cells, the policies at the source when feedback is disrupted, or when the source does not use the allocated rate, and the response to binary and explicit rate feedback. This dissertation work has helped design some of the source rules of the interna- tional standard (esp. SES Rules 5, 9, 11, and 13) and we shall examine the details later in this chapter. These rules can be broadly be considered as providing some open-loop functionality in ABR. SES Rules 5 and 13 deal with the problem of sources not using their allocated rates - the related policies are popularly called the Use-it-or-Lose-it policies. In a related work [53, 55], and in the introductory chapter 2, we consider parameter related issues in SES Rule 6. In Rule 9, we developed the \rescheduling" option to allow low rate sources to immediately use higher allocations. We helped develop SES Rule 11 which deals with the issue of low rate sources and out-of-rate 223
RM cells. In this chapter, we devote one section to the topic of Use-it-or-Lose-it policies, and another to the topic of low rate sources. 7.1 Use-It-or-Lose-It Policies The ABR framework is predominantly closed-loop, i.e., sources normally change their rates in response to network feedback. Another form of control is open-loop control where sources change their rates independent of network feedback. Open- loop control can complement closed-loop control when the network delays are large compared to application tra c chunks, or when network feedback is temporarily disrupted. It is also useful to control applications which are bursty or source bottle- necked. Bursty application tra c alternates between active periods (application has data to send) and idle periods (application has no data to send). Source-bottlenecked applications cannot sustain a data rate as high as the network allocated rate. The ATM Forum debated on the issue of using open-loop control to reduce rate alloca- tions of sources which do not use them. The proposed solutions, popularly known as the Use-It-or-Lose-It (UILI) policies, have had signi cant impact on the ABR ser- vice capabilities. In this section, we discuss and evaluate these policies, and their implications on the ABR service. This section is subdivided as follows. Section 7.1.1 discusses the issues in the design of UILI policies. We then discuss early UILI proposals in section 7.1.2. We identify the problems with the early proposals in section 7.1.3 and present the nal set of proposals which were debated in the ATM Forum in section 7.1.6. We then evaluate the performance of various alternatives in Section 7.1.12 and summarize the implications of UILI on ABR in section 7.1.13. 224
- Page 199 and 200: 6.14 ERICA+: Queue Length as a Seco
- 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: (a) Transmitted Cell Rate (basic ER
- Page 253 and 254: low. This tradeo was discovered and
- 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
RM cells. In this chapter, we devote one section to <strong>the</strong> topic of Use-it-or-Lose-it<br />
policies, and ano<strong>the</strong>r to <strong>the</strong> topic of low rate sources.<br />
7.1 Use-It-or-Lose-It Policies<br />
The <strong>ABR</strong> framework is predom<strong>in</strong>antly closed-loop, i.e., sources normally change<br />
<strong>the</strong>ir rates <strong>in</strong> response to network feedback. Ano<strong>the</strong>r <strong>for</strong>m of control is open-loop<br />
control where sources change <strong>the</strong>ir rates <strong>in</strong>dependent of network feedback. Open-<br />
loop control can complement closed-loop control when <strong>the</strong> network delays are large<br />
compared to application tra c chunks, or when network feedback is temporarily<br />
disrupted. It is also useful to control applications which are bursty or source bottle-<br />
necked. Bursty application tra c alternates between active periods (application has<br />
data to send) and idle periods (application has no data to send). Source-bottlenecked<br />
applications cannot susta<strong>in</strong> a data rate as high as <strong>the</strong> network allocated rate. The<br />
ATM Forum debated on <strong>the</strong> issue of us<strong>in</strong>g open-loop control to reduce rate alloca-<br />
tions of sources which do not use <strong>the</strong>m. The proposed solutions, popularly known<br />
as <strong>the</strong> Use-It-or-Lose-It (UILI) policies, have had signi cant impact on <strong>the</strong> <strong>ABR</strong> ser-<br />
vice capabilities. In this section, we discuss and evaluate <strong>the</strong>se policies, and <strong>the</strong>ir<br />
implications on <strong>the</strong> <strong>ABR</strong> service.<br />
This section is subdivided as follows. Section 7.1.1 discusses <strong>the</strong> issues <strong>in</strong> <strong>the</strong><br />
design of UILI policies. We <strong>the</strong>n discuss early UILI proposals <strong>in</strong> section 7.1.2. We<br />
identify <strong>the</strong> problems with <strong>the</strong> early proposals <strong>in</strong> section 7.1.3 and present <strong>the</strong> nal<br />
set of proposals which were debated <strong>in</strong> <strong>the</strong> ATM Forum <strong>in</strong> section 7.1.6. We <strong>the</strong>n<br />
evaluate <strong>the</strong> per<strong>for</strong>mance of various alternatives <strong>in</strong> Section 7.1.12 and summarize <strong>the</strong><br />
implications of UILI on <strong>ABR</strong> <strong>in</strong> section 7.1.13.<br />
224