******************************************************************* ATM Forum Document Number: ATM Forum/96-0178 ******************************************************************* Title: Comments on "Use-it or Lose-it" (Annex E of TM4.0) ******************************************************************* Abstract: Annex E of T4.0 describes several optional NIC implementations for the use-it or lose-it policies. A minor change in one of the options will result in significant performance improvements. ******************************************************************* Source: Raj Jain, Shiv Kalyanaraman, Rohit Goyal, Sonia Fahmy, and Fang Lu The Ohio State University Department of CIS Columbus, OH 43210-1277 Phone: 614-292-3989, Fax: 614-292-2911, Email: Jain@ACM.Org Saragur Srinidhi NASA Lewis Research Center and Sterling Software Scientific Systems Division 21000 Brookpark Road, MS 141-1 Cleveland,OH 44135 Phone: 216-433-8987, Fax: 216-433-8000 The presentation of this contribution at the ATM Forum is sponsored by NASA. ******************************************************************* Date: February, 1996, Los Angeles ******************************************************************* Distribution: ATM Forum Technical Working Group Members (Traffic Management) ******************************************************************* Notice: This contribution has been prepared to assist the ATM Forum. It is offered to the Forum as a basis for discussion and is not a binding proposal on the part of any of the contributing organizations. The statements are subject to change in form and content after further study. Specifically, the contributors reserve the right to add to, amend or modify the statements contained herein. ******************************************************************* Motion 1 (Major Comment): Change the following text in Normative Annex F, Page 82 of TM4.0 R10: End-system method 1: Forward RM triggered When a in-rate forward RM is sent, if the ACR exceeds the recent transmission rate plus a fixed bound, the ACR is reduced by a multiplicative factor and the next increase inhibited. Specifically, the recent rate R, could be estimated by Nrm divided by the time since the last in-rate forward RM-cell was sent. If ACR exceeds R+ICR, the ACR could be set to the higher of ACR*15/16 and R+ICR, and the next increase inhibited. to: -- End-system method 1: Forward RM triggered When a in-rate forward RM is sent, if the ACR exceeds the recent transmission rate the next increase is inhibited. Further, if the ACR exceeds the recent transmission rate plus a fixed bound, the ACR is reduced by a multiplicative factor. Specifically, the recent rate R, could be estimated by Nrm divided by the time since the last in-rate forward RM-cell was sent. If ACR exceeds R, the next increase is inhibited. If ACR exceeds R+ICR, the ACR is set to the higher of ACR*15/16 and R+ICR. Motion 2 (Major Comment): Change the following text in Normative Appendix I, Page 83-84 of TM4.0 R10: ACR-ok A flag indicating that the ACR passed the "TOF" test. ACR-ok = time <= TOF * Nrm / ACR ! S5 If not ACR-ok and ACR > ICR ! ACR is too high ACR = ACR - ACR*time*TDF ! S5a: idle adjust ACR = max(ACR,ICR) if receive RM(DIR=backward, CCR, ER, CI, NI, BN) ! S8: adjust ACR if CI=1 ACR = ACR - ACR*RDF ! do MD else if NI=0 and (ACR-ok or PNI) ! S5b ACR = ACR+Nrm*AIR ! do AI ACR = min(ACR, PCR) ACR = min(ACR, ER) ! S9 ACR = Max(ACR, MCR) ! S9 ACR-ok = true ! S5b TO: --- ACR-ok A flag indicating that source has no ACR retention R = Nrm/T ! Current rate ACR-ok = (ACR <= R) ! No retention if (ACR > R + ICR) ! ACR is too high ACR = Max(R + ICR, ACR*15/16) ! Optional adjustment if receive RM(DIR=backward, CCR, ER, CI, NI, BN) ! S8: adjust ACR if CI=1 ACR = ACR - ACR*RDF ! Do multiplicative decr else if NI=0 and ACR-ok ! Don't inhibit increase ACR = ACR + AIR ! Additive increase ACR = min(ACR, PCR) ACR = min(ACR, ER) ! S9 ACR = Max(ACR, MCR) ! S9 JUSTIFICATION FOR CHANGE: ------------------------ In December 1995 meeting, we presented an extensive comparison of various source-based options for source end-system rule 5. Rule 5 deals with the so-called "use-it or lose-it" policies. These policies limit the time for which a source may keep its allocated cell rate (ACR). If a source does not use it immediately after receiving the feedback (within the next forward RM cell), it starts reducing its ACR. The use-it or loose-it can be implemented in switches or in NICs (sources) or both. The advantage of switch-only implementation is that NICs are simpler. The advantage of NIC implementation is that switches can be more aggressive in their bandwidth allocation without worrying about long-term implications of any one allocation. Without source based allocations, the switches have to have enough buffers to absorb the traffic that may result from overallocation of bandwidth. Also, switches control has delayed effect in the sense that if a switch finds its available bandwidth reduced (due to higher priority VBR traffic) and it sends a feedback (via returning RM cells or via backward explicit congestion notification (BECN)), there is a time delay before which a source comes to know that it should not use its previous allocation. After considerable debate, the forum decided to require only a switch-based approach. NICs can keep their allocation for a time period (parameter ATDF) of the order of 500 ms after which they are required to reduce their ACR to ICR. Those NIC vendors that feel 500 ms is too long can optionally implement additional measures that further reduce their ACR. The normative Annex F lists several such optional policies. Example 1 in the Annex presents a so called "count-based" policy such that the sources reduce their ACR by a fixed factor 15/16 every Nrm cells. This is different from a "time-based" policy where the reduction is proportional to the time since the last FRM was sent. In our December contribution [1], we had made several arguments as to why count-based approach is better. While the example is very close to what we had suggested, there is a minor difference in the language. That minor difference in the language makes a major difference in performance and, therefore, we propose the change. One of key new results that we discovered via analysis was that the source should ignore increases continuously until it was able to use its previous allocation. Ignoring just once causes oscillations. We divided the operating region in three parts: 1. Source is sending below its ACR 2. Source is sending between ACR and ACR+ICR 3. Source is sending above ACR+ICR We showed that until the source reaches region 3, it should ignore all network directed increases. If this is not done, the ACR will jump to a high value and start decreasing towards ICR. This happens repeatedly resulting in continuous oscillations. During the periods when the source's ACR is much higher than its current rate, the network is subject to a sudden burst. The oscillations and resulting problem can be avoided having two tests: one to see if the next increase should be inhibited and a separate test to see if the source should reduce its current ACR. The first test is satisfied if ACR is less than or equal to R. The second test is satisfied if ACR is less than or equal to R+ICR. This is the proposed change. REFERENCES: ---------- [1] R.Jain, S.Kalyanaraman, R. Goyal, S.Fahmy, F.Lu, "A Fix for Source End System Rule 5," AF-TM 95-1660, December 1995. All our past ATM forum contributions and presentations can be obtained on-line: http://www.cse.wustl.edu/~jain/