Network Working Group J. Diederich Internet-Draft M. Zitterbart Expires: April 14, 2000 Technical University Braunschweig October 15, 1999 An Expedited Forwarding with Dropping PHB draft-dieder-diffserv-phb-efd-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 14, 2000. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document defines a new per-hop behavior (PHB) for Differentiated Services, the so-called 'Expedited Forwarding with Dropping' PHB. Packets marked for this PHB are forwarded with the same low-delay, low-jitter characteristics as packets marked with the Expedited Forwarding PHB, but may experience a certain probability of packet loss. This PHB is especially suited to provide low-delay services in cellular wireless networks. Note from the authors This document is in an early stage and may not conform to all requirements on defining per-hop behaviors as specified in [RFC2474] and [RFC2475]. Furthermore, it describes the concepts of the PHB only. A simulative evaluation is under way. Diederich & Zitterbart Expires April 14, 2000 [Page 1] Internet-Draft Expedited Forwarding with Dropping October 1999 1. Overview and motivation In Differentiated Services (DiffServ) [RFC2474] [RFC2475], the Expedited Forwarding (EF) PHB [RFC2598] can be used to provide a low-latency, low-jitter, assured bandwidth end-to-end service, the so-called Premium service [RFC2638]. This service appears to the endpoints like a 'virtual leased line'. Such a line may not always be in use to 100 percent so that traffic belonging to other PHBs can utilize unused resources (cf. section 2.2 in [RFC2638]). 1.1 Problem Description Currently, Assured Forwarding [RFC2597] traffic or Best Effort traffic may utilize unused EF resources. In both kinds of traffic, burstiness is allowed which can lead to large queues under heavy load situations. Therefore, packets from both may have already experienced delay in upstream DiffServ nodes or might experience delay later in downstream nodes. Thus, traffic from these services can not substantially benefit from the 'low-latency advantage' of utilizing unused EF resources. 1.2 A new per-hop behavior This document describes a new per-hop behavior called 'Expedited Forwarding with Dropping' (EFD). In general, packets marked for this PHB experience a low delay and a low jitter but can be dropped with a certain probability. Furthermore, EFD packet utilize unused EF resources. The EFD PHB can be used together with traffic conditioning actions at the DiffServ domain's boundary to create a so-called Best-Effort Low-Delay (BELD) service. It has the same low-latency, low-jitter characteristics as Premium service but gives an assured probability of packet loss and, thus, a loose assurance on the amount of bandwidth granted. This service can be used by real-time applications which require low-delay packet delivery but can tolerate packet loss or adapt to bandwidth variations up to a certain threshold. 1.3 Example: Low delay service for mobile terminals In a cellular wireless network, two additional issues have to be considered when providing a low-delay fixed bit-rate service similar to Premium service: Mobility of the terminals and the special characteristics of the radio channel, such as a higher bit error rate (cf. Appendix B for more details). 1. When a mobile terminal moves into a highly loaded area, the negotiated Premium service peak rate may not be available anymore. Since the Premium Service peak rate should be available with a high assurance as soon as the customer demands it, this case should occur only rarely. One proposal is to reserve a Diederich & Zitterbart Expires April 14, 2000 [Page 2] Internet-Draft Expedited Forwarding with Dropping October 1999 fraction of the Premium service bandwidth for handover purposes only. However, this increases the amount of unused Premium service resources compared to wired networks. 2. Due to the higher bit error rate on the radio channel, a certain amount of bandwidth on the radio link is used for error protection methods such as Forward Error Correction (FEC) or Automatic Repeat Request (ARQ). To assure the negotiated peak rate on the radio channel, a fraction of Premium service radio channel resources must be reserved for error protection methods. Otherwise, the negotiated peak rate will not be available under bad radio channel conditions with a high bit error rate. However, the average amount of bandwidth necessary for error protection will be below this fraction leading to unused Premium service resources. In summary, a higher fraction of Premium service resources may be unused when introducing EF-based low-delay services into a cellular wireless network. A further issue is that real-time applications on mobile hosts should deal with packet loss, anyway, e.g., due to short disruptions because of radio shadows. Thus, a service with low-delay and an assured drop rate is especially suited for cellular wireless networks. Since such a service can neither be provided with the EF PHB nor with the AF PHB (cf. Appendix B.5), another PHB such as the EFD PHB is necessary for this purpose. This document describes the EFD PHB. An otherwise DiffServ-compliant node is not required to implement this PHB in order to be considered DiffServ-compliant, but when a DiffServ-compliant node is said to implement the EFD PHB, it must conform to the specification in this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Description of the EFD per-hop behavior EFD packets utilize unused EF resources. Therefore, a DiffServ node implementing the EFD PHB MUST implement the EF PHB according to [RFC2598]. There are the following requirements on the behavior of an EFD compatible DiffServ node: o The maximum delay a single EFD packet experiences in a DiffServ node MUST NOT be greater than the maximum delay an EF packet may experience. No such requirement exists for the average delay a single EFD packet experiences. o The maximum delay a single EF packet experiences in a DiffServ node MUST NOT be larger than without any EFD packets. If an EF Diederich & Zitterbart Expires April 14, 2000 [Page 3] Internet-Draft Expedited Forwarding with Dropping October 1999 packet arrives and there are not sufficient resources available for the incoming EF packet, EFD packets MUST release sufficient EF resources immediately so that the EF packet does not experience a higher dropping probability as if there would be no EFD packets. o EFD packets MUST NOT be preferentially forwarded compared to EF packets. EF packets MAY be preferentially forwarded compared to EFD packets as long as the maximum delay requirement is not violated. In general, both SHOULD experience the same forwarding behavior except for the higher dropping probability of EFD packets. 3. Recommended Codepoint To be assigned. 4. Mutability Packets marked for the EFD PHB MAY be remarked at a DiffServ boundary to other codepoints that satisfy the EFD PHB. Packets marked for the EFD PHB MAY be promoted to the EF PHB by a DiffServ domain but SHOULD NOT be demoted or promoted to another PHB. 5. Tunneling When EFD packets are tunneled, the tunneling packets must be marked as EFD or EF to keep the low-delay characteristic. 6. Interaction with other PHBs The EFD PHB can only be implemented in connection with the EF PHB. Thus, both build a so-called PHB group, providing a low-delay forwarding with two drop precedences: almost no probability of dropping a packet for the EF PHB and a certain drop probability for the EFD PHB depending on the traffic conditioning actions belonging to the service build with the EFD PHB. 6.1 Impact of EFD traffic on EF traffic Due to the introduction of EFD packets, the utilization of EF buffer resources will be higher than with EF packets only. Thus, the average delay of EF packets increases. However, the maximum delay bound as described in Appendix A is not influenced. It still can be guaranteed for both, EF packets and EFD packets since the amount of EF buffering resources is independent from the EFD PHB implementation. For a single EF packet, there is no difference with regard to maximum delay if other EF packets or EFD packets utilize the EF resources as long as the buffer size remains Diederich & Zitterbart Expires April 14, 2000 [Page 4] Internet-Draft Expedited Forwarding with Dropping October 1999 the same. Furthermore, the introduction of large EFD packets compared to small EF packets may lead to a larger jitter within EF traffic. This impact depends on the implementation of the scheduling for the EFD PHB (Section 7.3) and can be smoothened by means of traffic conditioning Appendix B.5. 6.2 Impact of EFD traffic on AF traffic Since EFD packets utilized EF resources only, the impact of EFD packets on AF is the same as if EF packets would use the EF resources. As the EF's share of the total bandwidth on a link will be rather low, this impact should be negligible. 7. Example mechanisms to implement the EFD PHB It is assumed that the queueing mechanisms as described in [RFC2598] (e.g., strict priority queuing, Weighted Fair queuing) ensure that EF / EFD packets are treated preferentially compared to packets belonging to other PHBs. In this section, we only consider scheduling or queueing issues related to the internal handling of the EF / EFD buffer. 7.1 EFD packet arrival An example implementation of the EFD PHB might process EFD packets as follows: o If the output link is idle and there are no EF packets to sent, forward the EFD packet immediately. o If the output link is not idle, store the incoming EFD in the EF buffer as long as there is sufficient buffer capacity. o If there is insufficient space to store the incoming EFD packet in the EF buffer, it is dropped. Remarking instead of dropping is not envisioned since it would lead to the possibility of packet reordering. 7.2 EF packet arrival If an EF packet arrives, the following new situation has to be considered. There is insufficient space in the EF buffer to store the incoming EF packet but there are EFD packets within the buffer. In this case, EFD packets must be removed from the buffer so that the EF packet can be stored. Depending on the buffer implementation, a handling of free buffer space fragmentation must be considered, for example, if EFD packets are smaller than EF packets. Diederich & Zitterbart Expires April 14, 2000 [Page 5] Internet-Draft Expedited Forwarding with Dropping October 1999 7.3 Scheduling strategies Since the introduction of EFD packets leads to a higher utilization of EF buffers, the scheduling strategies within the EF buffer have an influence on the impact of EFD packets on EF packets. For example, the impact of large EFD packets on small EF packets may be lessened using separate queues for both with a common bounded size and Weighted Fair Queueing (WFQ). 8. Security considerations Since the EFD PHB has no own resources assigned but uses EF resources instead, the same security considerations have to be made as for the EF PHB except for one change: Dropping EFD packets is a fundamental behavior of this PHB. Thus, these drops MAY be noted but they definitely cannot be used to identify security attacks. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2474] Nichols, K., Blake, S., Baker, F. and D. L. Black, "Definition of the Differentiated Services Field (DS} Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D.L., Carlson, M. A., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999. [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC2638] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999. [QBone] Teitelbaum, B., "QBone Architecture (v1.0)", Internet2 QoS Working Group Draft, August 1999. Work in progress. Diederich & Zitterbart Expires April 14, 2000 [Page 6] Internet-Draft Expedited Forwarding with Dropping October 1999 Authors' Addresses Joerg Diederich Technical University Braunschweig Bueltenweg 74/75 D-38106 Braunschweig Germany Phone: +49 531 391 3265 Fax: +49 531 391 5936 EMail: dieder@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/~dieder Martina Zitterbart Technical University Braunschweig Bueltenweg 74/75 D-38106 Braunschweig Germany Phone: +49 531 391 3288 Fax: +49 531 391 5936 EMail: zitterbart@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/~zit Appendix A. Buffer size and maximum delay in Expedited Forwarding In EF, generally only very small queues are necessary as traffic conditioning has to ensure that the arrival rate of the EF aggregate is always less than the departure rate. However, the following worst case scenario has to be considered [QBone]. o The output link is currently busy due to the transmission of a packet of another PHB. o MTU-sized EF packets arrive synchronized on all incoming links. The size of the EF buffer for each output link must accommodate to this worst case, since it is no traffic conditioning issue. Therefore, the EF buffer must be able to store one MTU-sized EF packet per incoming interface. Thus, the minimal EF buffer size for each outgoing link is the sum of the MTUs of each incoming interface. The maximum delay an EF packet experiences in a single DiffServ node results from this buffer size and the bandwidth of the outgoing link. For example, if a node has 10 incoming interfaces all with the same MTU of 1500 Bytes and the EF bandwidth of the outgoing link is 15 MBit/s, the maximum delay for an MTU sized EF packet is: (10 * 1500 Bytes) / 15 MBit/s = 8 ms. Diederich & Zitterbart Expires April 14, 2000 [Page 7] Internet-Draft Expedited Forwarding with Dropping October 1999 Appendix B. Low-delay services in wireless cellular networks using DiffServ Before introducing Differentiated Services in wireless cellular networks, the special characteristics of wireless and mobile communication have to be carefully evaluated. This section discusses some selected issues. B.1 Characteristics of wireless communication In wireless communication, there is a higher bit-error rate on the radio channel (e.g., due to channel interference, fading, etc.). In most cellular systems, error protection methods on the radio link try to accommodate to high bit-errors rate. Two groups of methods are currently in use: Forward Error Correction (FEC) methods and Automatic Repeat Request (ARQ) methods. Both need additional radio link capacity (the former for redundancy, the latter for retransmissions). B.2 Characteristics of mobile communication When providing quality of service in cellular networks, special attention has to be paid to handover between different cells: Routes to or from mobile hosts within the wireless network may change during a single communication session. Thus, also the amount of available resources may change, for example when a mobile host moves into a heavily loaded cell. In this case, even a blocking of the communication session (called handover blocking) cannot be completely avoided. B.3 Analysis of Premium service Premium service is a low-delay service currently discussed in the context of Differentiated Services. It is specified by means of a peak-rate and this rate is expected to be available as soon as data from the customer is sent. When providing a service most similar to Premium service in wireless networks, one problem arises from mobility: When a mobile hosts moves into a neighbored cell, there may not be sufficient bandwidth available to support the same service as in the previous cell (we do not consider pre-reservations in other cells because we do not think that a movement can be predicted in general). Since the users within the cell should not experience unlimited QoS degradation, admission control may deny the handover request in the worst case. Furthermore, dimensioning the necessary amount of radio channel resources to achieve the negotiated user peak rate is rather difficult. To accommodate to bit errors, error protection methods Diederich & Zitterbart Expires April 14, 2000 [Page 8] Internet-Draft Expedited Forwarding with Dropping October 1999 are widely used. The amount of radio channel resources for error protections depends on the radio channel characteristics. To provide the peak rate even under high bit error rates, the reserved amount of radio channel resources must be chosen according to the strongest necessary error protection. In situations with an average bit error rate, the error protection can be weaker so that it needs less radio channel resources. Thus, unused reserved resources can be utilized by packets belonging to other services. As connectivity throughout the whole communication session is the most important QoS parameter, the current low-delay, low-jitter, assured bandwidth Premium Service can be provided to mobile users only when a high fraction of Premium service resources are reserved for handover purposes, or bad channel characteristics etc. Thus, only few users may be able to get such a service. B.4 Proposals for mobile low-delay services We propose three different low-delay services for cellular wireless networks: o Premium service o Mobile Premium service o Best-Effort low-delay service Premium service [RFC2638] may be provided to wireless attached hosts which do not perform handover during an ongoing communication session (called portable hosts). However, due to a possible higher bit error rate of the radio channel, the bandwidth assurance may not be as strict as in wired networks and the delay may be higher (higher propagation delay due to a lower bit rate as in fixed networks). Mobile Premium service is defined as a low-delay, low-jitter service such as Premium service. However, the assurance on the amount of bandwidth is bipartite: Without handover, a mobile terminal will keep its assigned bandwidth as described in the previous paragraph on Premium service. With handover, the amount of bandwidth, assigned in the old cell, will be available in the new cell with a certain probability only which depends on the amount of bandwidth reserved for handover purposes as well as on other handover activities. Thus, for the handover blocking rate, only a statistical guarantee can be issued. In this way, a change in the quality of Mobile Premium service is always caused by movements of the mobile terminal itself, but not due to mobility of other mobile hosts: If the mobile terminal does not move out of the cell, it will keep its assigned bandwidth. If it moves into another cell, it might experience handover blocking. Best-Effort low-delay (BELD) service has the same low-delay, Diederich & Zitterbart Expires April 14, 2000 [Page 9] Internet-Draft Expedited Forwarding with Dropping October 1999 low-jitter, assured handover blocking rate characteristic as Mobile Premium service and additionally a certain probability of packet drop. Thus, the bandwidth assurance is less tight as for Mobile Premium service or Premium service. In contrast to Mobile Premium service, the quality of the BELD service depends on both, the mobility of the service owner itself and on the mobility of other Mobile Premium service / BELD service owners: The assigned bandwidth may change even if the mobile terminal does not move at all. Real-time Applications using these three services must be prepared to deal with occasional packet loss or short disruptions due to the radio channel characteristics. Differences between these services exist in the statistical drop rate (and thus the assured bandwidth), which is lowest for Premium service and highest for BELD service. Example applications may be for Premium service a high-end IP telephony (no handover support), for Mobile Premium service a high-end mobile IP telephony, and a low-cost mobile IP telephony for the BELD service. This last application may use coders, which can adapt to a varying amount of bandwidth by adapting the speech quality whereas the users of such an application accept the varying speech quality due to a lower price compared to the high-end Mobile Premium service. B.5 Possible Implementations of the proposed services Premium service for portable hosts may be implemented with the EF PHB in internal nodes and a more conservative admission control as in wired networks. This admission control accommodates to the varying bit error rates on the radio link by reserving a fraction of bandwidth for error protection in case that a higher bit error rate enforces a strong error protection. Mobile Premium service may be implemented with the EF PHB, as well, and a much more conservative admission control as for Premium service: A certain fraction of bandwidth may be reserved for handover purposes only so that new potential Premium service / Mobile Premium service users will be blocked early. The Best-Effort Low Delay (BELD) Service cannot be constructed from existing PHBs: The AF PHB allows queueing to accommodate to bursty traffic, leading to a higher delay. The EF PHB states in the security consideration section that packet loss due to overflow of the EF queue should never occur and should be noted as possible attacks or serious misconfiguration. For BELD service, packet loss is an inherent feature for applications which can tolerate it. Therefore, the EF PHB can not be used for building a BELD service, as well. Thus, BELD service is constructed from the EFD PHB and the following Diederich & Zitterbart Expires April 14, 2000 [Page 10] Internet-Draft Expedited Forwarding with Dropping October 1999 traffic conditioning at the DiffServ domain's boundary: The traffic conditioning must make sure that the given loose bandwidth assurance is met by restricting the amount of EFD traffic injected into the DiffServ domain. In this way, packet loss of EFD traffic should be kept under control. EF resources which are not used by EFD packets, may be utilized by packets marked for AF or Best-Effort. Traffic conditioning may also take actions to lessen the impact of large EFD packets on small EF packets. For example, it can simply deny long EFD packets or perform packet fragmentation. B.6 Deployment of DiffServ in mobile environments To gain experience with the bandwidth assurance, a service provider can give for a certain DiffServ domain, the amount of EFD traffic injected into this domain should be increased slowly while watching the loss rate of the EFD traffic. The loss rate will depend on several factors like the current traffic pattern of EF traffic, and, thus, the time of day or the day of the week. The EFD PHB and the EF PHB can be deployed in three variants: EF only, EFD only, and both coexisting. The first case describes the current DiffServ with AF / Best-Effort traffic utilizing unused EF resources. In the second case, EF traffic is generally not injected into the DiffServ domain, so that EFD traffic can utilize most of the common EF resources. This may be the case for wireless networks, where the network provider does not want to offer Premium Service or Mobile Premium service. The third case describes a coexistence between EF traffic and EFD traffic. For the specification of the EFD PHB, this last case has been given most attention. Diederich & Zitterbart Expires April 14, 2000 [Page 11] Internet-Draft Expedited Forwarding with Dropping October 1999 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Diederich & Zitterbart Expires April 14, 2000 [Page 12]