INTERNET-DRAFT Octavio Medina Internet Engineering Task Force Francis Dupont Expires December 2000 Laurent Toutain ENST Bretagne A proposal for the use of ECN bits with UDP flows 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document contains a proposal for the use of ECN bits with UDP packets. For the moment, the presence of ECN bits in the IP header of UDP streams is useless. These bits could be used to identify IP/UDP/RTP encapsulated data at routers prior to header compression and other specific operations. 1. Introduction The use of RTP for the transport of audio and video flows is becoming a current practice on the Internet. With the increase on the number of applications generating this type of data, it becomes interesting to consider how network nodes could be optimized to process these Medina, Dupont, Toutain Expires December 2000 [Page 1] INTERNET-DRAFT draft-medina-ecn-udp-00.txt July 2000 flows. The RTP protocol is based on Application Layer Framing concepts. It means that only at the application level there exists the knowledge and the capability to handle the information. The network in this case can be seen as a black box and applications have to adapt to its behavior. If such a mechanism corresponds to the end-to-end approach used in the Internet, in some situations, it might be a good idea to give to the network some knowledge of RTP flows. The main case is header compression. Header compression has been proposed to improve transmission rates over slow links. The utility of the mechanism has been validated by the large deployment of TCP/IP header compression [1], but also with the use of a similar method to compress the combined RTP/UDP/IP headers [2]. Having IPv6 consolidating itself as the network protocol of tomorrow's Internet, it becomes even more attractive to perform header compression. The IPv6 header is formed of 40 bytes without extension headers [3]. For IP telephony flows, a popular application today, a considerable overhead is introduced by IPv6 if we consider that the payload of telephony packets is usually small. Header compression may not be reserved to slow links, but it can also be useful for communication between IPTel gateways for example. In order to perform compression, network nodes need first to identify the protocol suite contained in the packet. In the case of RTP, nodes need to find the UDP header (which may be a little complex in IPv6 if extensions are used) and then look for an RTP header. This operation is performed for every packet crossing the interface. Having a standard and simple method to identify RTP/UDP/IP packets could reduce the computing power needed to cleverly forward these type of flows. 2. Proposal This draft proposes the use of a flag in the IP header to indicate the presence of RTP/UDP/IP headers in the packet. We propose to use the CU (Currently Unused) bits in the DS field [4] for both IPv4 and IPv6. The CU bits could potentially be used for Early Congestion Notification [5] in the near future. Our proposal does not affect the operation of this mechanism. In the proposal to add Explicit Congestion Notification (ECN) [5] the semantic of the CU bits is defined as: - ECT (ECN-Capable Transport: bit 6 of the DiffServ Byte) announces to the router that the source and the destination can do explicit congestion notification. - CE (Congestion Experienced: Bit 7 of the DiffServ Byte) indicates a congestion on the path. We propose to extend this semantic to UDP packets. We consider two approaches: Medina, Dupont, Toutain Expires December 2000 [Page 2] INTERNET-DRAFT draft-medina-ecn-udp-00.txt July 2000 First Approach: CU bits: 1x, protocol: UDP. indicates an RTP stream with congestion control. This approach supposes the use of the ECN method for RTP flows. This approach implies the implementation of TCP-friendly methods at the application level, to be performed by RTP senders/receivers. Second Approach: CU bits: 01. indicates an RTP stream without congestion control. This second option consists in adding a flag in the IP header to identify non-adaptive RTP flows. The proposed bit combination is not used by ECN, therefore its use should be transparent to the mechanism. This flag could mainly be used to accelerate packet classification prior to header compression. Alternatively, the explicit indication of non-adaptive flows could be used by queue management mechanisms such as RED [6] to better protect TCP-friendly flows by dropping non-adaptive packets first when congestion is experienced. Of course, the relationship between such an idea and the ongoing works on DiffServ needs to be studied. 3. Tunneling The mapping of DSCP and ECN values over tunneling interfaces is a question. The mapping of the proposed "RTP flag" between encapsulating and encapsulated headers follow the same principles as those presented in [7]. 4. Security Considerations This proposal introduces no new security issue, section 9 of the ECN document and the whole [7] deal with security considerations for ECN. 5. References [1] V. Jacobson; "TCP/IP Compression for Low-Speed Serial Links", RFC 1144; February 1990. [2] S. Casner, V. Jacobson; "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links"; RFC 2508; February 1999. [3] S. Deering, R. Hinden; "Internet Protocol, Version 6 Specification"; RFC 1883, December 1995. [4] K. Nichols, S. Blade et al; "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers"; RFC 2474; December 1998. [5] K. Ramakrishnan, S. Floyd; "A Proposal to add Explicit Congestion Medina, Dupont, Toutain Expires December 2000 [Page 3] INTERNET-DRAFT draft-medina-ecn-udp-00.txt July 2000 Notification (ECN) to IP"; RFC 2481; January 1999. [6] S. Floyd, V. Jacobson; "Random Early Detection gateways for Congestion Avoidance"; IEEE/ACM Transactions on Networking, Volume 1, Number 4, August 1993, pp. 397-413. [7] S. Floyd, K. K. Ramakrishnan; "ECN Interactions with IP Tunnels"; draft-floyd-ecn-tunnels-00.txt; April 2000. 8. Authors' Address Octavio MEDINA, Francis DUPONT, Laurent TOUTAIN Ecole Nationale des T‰l‰communications de Bretagne Campus de Rennes 3, rue de la Ch‚taigneraie 35510 CESSON-SEVIGNE France Email: {medina, dupont, toutain}@rennes.enst-bretagne.fr Medina, Dupont, Toutain Expires December 2000 [Page 4]