Transport Area Working Group J. Saldana Internet-Draft University of Zaragoza Obsoletes: 4170 (if approved) D. Wing Intended status: BCP Cisco Systems Expires: September 1, 2012 J. Fernandez Navajas University of Zaragoza Muthu A M. Perumal Cisco Systems G. Camarillo Ericsson Research February 29, 2012 Tunneling Compressed Multiplexed Traffic Flows (TCMTF) draft-saldana-tsvwg-tcmtf-01 Abstract This document describes a method to improve the bandwidth utilization of network paths that carry multiple streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple streams are carried over that path. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 1, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Saldana, et al. Expires September 1, 2012 [Page 1] Internet-Draft TCMTF February 2012 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Bandwidth efficiency of real-time flows . . . . . . . . . 3 1.3. Real-time applications not using RTP . . . . . . . . . . . 4 1.4. Scenarios of application . . . . . . . . . . . . . . . . . 5 1.5. Objective of this standard . . . . . . . . . . . . . . . . 5 1.6. Overview of Protocols . . . . . . . . . . . . . . . . . . 6 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Models of implementation . . . . . . . . . . . . . . . . . 8 2.2. Choice of the compressing protocol . . . . . . . . . . . . 9 2.2.1. Context Synchronization in ECRTP . . . . . . . . . . . 10 2.2.2. Context Synchronization in ROHC . . . . . . . . . . . 10 2.3. Multiplexing . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Tunneling Inefficiencies . . . . . . . . . . . . . . . 11 2.4. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5. Encapsulation Formats . . . . . . . . . . . . . . . . . . 11 3. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Saldana, et al. Expires September 1, 2012 [Page 2] Internet-Draft TCMTF February 2012 1. Introduction This document describes a way to combine existing protocols for compression, multiplexing, and tunneling to save bandwidth for some applications that generate small packets, such as real-time ones. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 1.2. Bandwidth efficiency of real-time flows In the last years we are witnessing the raise of new real-time services that use the Internet for the delivery of interactive multimedia applications. The most common of these services is VoIP, but many others have been developed, and are experiencing a significant growth: videoconferencing, telemedicine, video vigilance, online gaming, etc. The first design of the Internet did not include any mechanism capable of guaranteeing an upper bound for delivery delay, taking into account that the first deployed services were e-mail, file transfer, etc., in which delay is not critical. RTP [RTP] was first defined in 1996 in order to permit the delivery of real-time contents. Nowadays, although there are a variety of protocols used for signaling real-time flows (SIP [SIP], H.323, etc.), RTP has become the standard par excellence for the delivery of real-time content. RTP was designed to work over UDP datagrams. This implies that an IPv4 packet carrying real-time information has to include 40 bytes of headers: 20 for IPv4 header, 8 for UDP, and 12 for RTP. This overhead is significant, taking into account that many real-time services send very small payloads. It becomes even more significant with IPv6 packets, as the basic IPv6 header is twice the size of the IPv4 header (Table 1). Saldana, et al. Expires September 1, 2012 [Page 3] Internet-Draft TCMTF February 2012 +---------------------------------+---------------------------------+ | IPv4 | IPv6 | +---------------------------------+---------------------------------+ | IPv4+UDP+RTP: 40 bytes header | IPv6+UDP+RTP: 60 bytes header | | G.711 at 20 ms packetization: | G.711 at 20 ms packetization: | | 25% header overhead | 37.5% header overhead | | G.729 at 20 ms packetization: | G.729 at 20 ms packetization: | | 200% header overhead | 300% header overhead | +---------------------------------+---------------------------------+ Table 1: Efficiency of different voice codecs In order to mitigate this bad network efficiency, the multiplexing of a number of payloads into a single packet can be considered as a solution. If we have only one flow, the number of samples included in a packet can be increased, but at the cost of adding new packetization delays. However, if a number of flows share the same path between an origin and a destination, a multiplexer can build a bigger packet in which a number of payloads share a common header. A demultiplexer is necessary at the end of the common path, so as to rebuild the packets as they were originally sent, making multiplexing a transparent process for the extremes of the flow. The headers of the original packets can be compressed to save more bandwidth, taking into account that there exist some header compressing standards ([cRTP], [ECRTP], [IPHC], [ROHC]). When different headers are compressed together, tunneling can be used to relieve intermediate routers from the decompression and compression processing. 1.3. Real-time applications not using RTP But there are many real-time applications that do not use RTP. Some of them send UDP packets, e.g. First Person Shooter (FPS) online games, for which latency is very critical. There is also another fact which has to be taken into account: TCP is getting used for media delivery. For many reasons, such as avoiding firewalls, the standard RTP/UDP/IP protocol stack is substituted in many cases by FLV/HTTP/TCP/IP (FLash Video [FLV]). There is also another kind of applications which have been reported as real-time using TCP: MMORPGs (Massively Multiplayer Online Role Playing Games), which in some cases have millions of players, thousands of them sharing the same virtual world. They use TCP packets to send the player commands to the server, and also to send to the player's application the characteristics and situation of other gamers' avatars. These games do not have the same interactivity of FPSs, but the quickness and the movements of the Saldana, et al. Expires September 1, 2012 [Page 4] Internet-Draft TCMTF February 2012 player are important, and can decide if they win or lose a fight. 1.4. Scenarios of application Different scenarios of application can be considered for the tunneling, compressing and multiplexing solution: for example, voice trunking between gateways of different offices of an enterprise. Also, the traffic of the users of an application in a town or a district, which can be multiplexed and sent to the central server. Also Internet cafes are suitable of having many users of the same application (e.g. a game) sharing the same access link. Another interesting scenario are satellite communication links that often manage the bandwidth by limiting the transmission rate, measured in packets per second (pps), to and from the satellite. Applications like VoIP that generate a large number of small packets can easily fill the limited number of pps slots, limiting the throughput across such links. As an example, a G.729a voice call generates 50 pps at 20 ms packetization time. If the satellite transmission allows 1,500 pps, the number of simultaneous voice calls is limited to 30. This results in poor utilization of the satellite link's bandwidth as well as places a low bound on the number of voice calls that can utilize the link simultaneously. Multiplexing small packets into one packet for transmission would improve the efficiency. Satellite links would also find it useful to multiplex small TCP packets into one packet. This could be especially interesting for compressing TCP ACKs. There is still another interesting use case: desktop or application sharing where the traffic from the server to the client typically consists of the delta of screen updates. Also, the standard for remote desktop sharing emerging for WebRTC in the RTCWEB Working Group is: {something}/SCTP/UDP (Stream Control Transmission Protocol [SCTP]). In this scenario, SCTP/UDP could be used in other cases: chatting, file sharing and applications related to WebRTC peers. There could be hundreds of clients at a site talking to a server located at a datacenter over a WAN. Compressing, multiplexing and tunneling this traffic could save WAN bandwidth and potentially improve latency. 1.5. Objective of this standard In conclusion, a standard that multiplexes, compresses and sends packets using a tunnel can be interesting for many enterprises: developers of VoIP systems can include this option in their solutions; or game providers, who can achieve bandwidth savings in their supporting infrastructures. Other fact that has to be taken into account is that the technique not only saves bandwidth but also Saldana, et al. Expires September 1, 2012 [Page 5] Internet-Draft TCMTF February 2012 reduces the number of packets per second, which sometimes can be a bottleneck for a satellite link or even for a network router. If only one stream is tunneled and compressed, then little bandwidth savings will be obtained. In contrast, multiplexing is helpful to amortize the overhead of the tunnel header over many payloads. 1.6. Overview of Protocols The current standard [TCRTP] defines a way to combine different standard protocols. Three layers are considered, as shown in the figure: RTP/UDP | | ---------------------------- | ECRTP compressing layer | | ---------------------------- | PPPMUX multiplexing layer | | ---------------------------- | L2TP tunneling layer | | ---------------------------- | IP Figure 1 In contrast, the new proposal includes other protocols to be compressed in addition to RTP/UDP, since real-time services can also be provided using UDP or TCP. Saldana, et al. Expires September 1, 2012 [Page 6] Internet-Draft TCMTF February 2012 TCP UDP RTP/UDP | | | \ | / ------------------------------ \ | / Nothing or ROHC or ECRTP or IPHC header compressing layer | | ------------------------------ | PPPMUX or other mux protocols multiplexing layer | | ------------------------------ | GRE or L2TP or other tunneling layer | | ------------------------------ IP Figure 2 Each of the three layers is considered as independent of the other two, i.e. different combinations of protocols can be implemented according to the new standard: o Regarding compression, a number of options can be considered: as the standards are able to compress different headers, the one to be used could be selected depending on the traffic to compress. It also exists the possibility of having a null header compression, in the case of wanting to avoid traffic compression, taking into account the need of storing a context for every flow and the problems of context desynchronization in certain scenarios. For this, different header compression protocols have been defined ([cRTP], [ECRTP], [IPHC], [ROHC]) by the IETF. o Multiplexing is accomplished using PPP Multiplexing [PPP-MUX]. Nevertheless, other multiplexing protocols can also be considered. o Tunneling is accomplished by using L2TP (Layer 2 Tunneling Protocol [L2TPv3]), GRE (Generic Routing Encapsulation [GRE]) or other schemes. Payload compression schemes could also be used, but they are not the aim of this standard. 2. Protocol Operation This section describes how to combine three protocols: compressing, multiplexing, and tunneling, to save bandwidth for real-time Saldana, et al. Expires September 1, 2012 [Page 7] Internet-Draft TCMTF February 2012 applications. 2.1. Models of implementation TCMTF can be implemented in different ways. The most straightforward is to implement it in the devices terminating the real-time streams (these devices can be e.g. voice gateways, or proxies grouping a number of flows): [ending device]---[ending device] ^ | TCMTF over IP Figure 3 Another way TCMTF can be implemented is with an external concentration device. This device could be placed at strategic places in the network and could dynamically create and destroy TCMTF sessions without the participation of the endpoints that generate real-time flows. [ending device]\ /[ending device] [ending device]---[concentrator]---[concentrator]---[ending device] [ending device]/ \[ending device] ^ ^ ^ | | | Native IP TCMTF over IP Native IP Figure 4 Such a design also allows classical compressing protocols to be used on links with only a few active flows per link. Saldana, et al. Expires September 1, 2012 [Page 8] Internet-Draft TCMTF February 2012 [ending device]\ /[ending device] [ending device]---[concentrator]---[concentrator]---[ending device] [ending device]/ \[ending device] ^ ^ ^ | | | Compressed TCMTF over IP Compressed Figure 5 2.2. Choice of the compressing protocol There are different protocols that can be used for compressing real- time flows: o IPHC (IP Header Compression [IPHC]) permits the compression of TCP/IP, UDP/IP and ESP/IP headers (Encapsulating Security Payload [ESP]). It has a low implementation complexity. On the other hand, the resynchronization of the context can be slow over long RTT links. It should be used in scenarios presenting very low packet loss percentage. o cRTP (compressed RTP [cRTP]) works the same way as IPHC, but is also able to compress RTP headers. The link layer transport is not specified, but typically PPP is used. For cRTP to compress headers, it must be implemented on each PPP link. A lot of context is required to successfully run cRTP, and memory and processing requirements are high, especially if multiple hops must implement cRTP to save bandwidth on each of the hops. At higher line rates, cRTP's processor consumption becomes prohibitively expensive. cRTP is not suitable over long-delay WAN links commonly used when tunneling, as proposed by this document. To avoid the per-hop expense of cRTP, a simplistic solution is to use cRTP with L2TP to achieve end-to-end cRTP. However, cRTP is only suitable for links with low delay and low loss. However, once multiple router hops are involved, cRTP's expectation of low delay and low loss can no longer be met. Further, packets can arrive out of order. o ECRTP (Enhanced Compressed RTP [ECRTP]) is an extension of cRTP [cRTP] that provides tolerance to packet loss and packet reordering between compressor and decompressor. Thus, ECRTP should be used instead of cRTP. o ROHC (RObust Header Compression [ROHC]) is able to compress TCP/IP, UDP/IP, ESP/IP and RTP/UDP/IP headers. It is a robust scheme developed for header compression over links with high bit error rate, such as wireless ones. It incorporates mechanisms for Saldana, et al. Expires September 1, 2012 [Page 9] Internet-Draft TCMTF February 2012 quick resynchronization of the context. It includes an improved encoding scheme for compressing the header fields that change dynamically. Its main drawback is that it requires significantly more processing and memory resources than the ones necessary for IPHC or ECRTP. This standard does not determine which of the existing protocols has to be used for the compressing layer. The decision will depend on the scenario, and will mainly be determined by the packet loss probability, RTT, and the availability of memory and processing resources. The standard is also suitable to include other compressing schemes that may be further developed. 2.2.1. Context Synchronization in ECRTP When the compressor receives an RTP packet that has an unpredicted change in the RTP header, the compressor should send a COMPRESSED_UDP packet (described in [ECRTP]) to synchronize the ECRTP decompressor state. The COMPRESSED_UDP packet updates the RTP context in the decompressor. To ensure delivery of updates of context variables, COMPRESSED_UDP packets should be delivered using the robust operation described in [ECRTP]. Because the "twice" algorithm described in [ECRTP] relies on UDP checksums, the IP stack on the RTP transmitter should transmit UDP checksums. If UDP checksums are not used, the ECRTP compressor should use the cRTP Headers checksum described in [ECRTP]. 2.2.2. Context Synchronization in ROHC ROHC [ROHC] includes a more complex mechanism in order to maintain context synchronization. It has different operation modes and defines compressor states which change depending on link behavior. 2.3. Multiplexing Header compressing algorithms require a layer two protocol that allows identifying different protocols. PPP [PPP] is suited for this, although other multiplexing protocols can also be used for this layer of TCMTF. When header compression is used inside of a tunnel, it will reduce the size of the IP, UDP, and IP headers of the IP packet carried in the tunnel. However, the tunnel itself has overhead due to its IP header and the tunnel header (the information necessary to identify the tunneled payload). One way to reduce the overhead of the IP Saldana, et al. Expires September 1, 2012 [Page 10] Internet-Draft TCMTF February 2012 header and tunnel header is to multiplex multiple real-time payloads in a single tunneled packet. 2.3.1. Tunneling Inefficiencies To get reasonable bandwidth efficiency using multiplexing within an L2TP tunnel, multiple real-time streams should be active between the source and destination of an L2TP tunnel. The packet size of the real-time streams has to be small in order to permit a good bandwidth saving. If the source and destination of the L2TP tunnel are the same as the source and destination of the compressing protocol sessions, then the source and destination must have multiple active real-time streams to get any benefit from multiplexing. Because of this limitation, TCMTF is mostly useful for applications where many real-time sessions run between a pair of endpoints. The number of simultaneous sessions required to reduce the header overhead to the desired level depends on the size of the L2TP header. A smaller L2TP header will result in fewer simultaneous sessions being required to produce adequate bandwidth efficiencies. 2.4. Tunneling L2TP tunnels should be used to tunnel the ECRTP payloads end to end. L2TP includes methods for tunneling messages used in PPP session establishment, such as NCP (Network Control Protocol). This allows [IPCP-HC] to negotiate ECRTP compression/decompression parameters. Other tunneling schemes, such as GRE [GRE] may also be used to implement the tunneling layer of TCMTF. 2.5. Encapsulation Formats The packet format for a packet compressed is: Saldana, et al. Expires September 1, 2012 [Page 11] Internet-Draft TCMTF February 2012 +------------+-----------------------+ | | | | Compr | | | Header | Data | | | | | | | +------------+-----------------------+ Figure 6 The packet format of a multiplexed PPP packet as defined by [PPP-MUX] is: +-------+---+------+-------+-----+ +---+------+-------+-----+ | Mux |P L| | | | |P L| | | | | PPP |F X|Len1 | PPP | | |F X|LenN | PPP | | | Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN| | Field | | Field1| | | |FieldN | | | (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | | +-------+----------+-------+-----+ +----------+-------+-----+ Figure 7 The combined format used for TCMTF with a single payload is all of the above packets concatenated. Here is an example with one payload: +------+------+-------+----------+-------+--------+----+ | IP |Tunnel| Mux |P L| | | | | |header|header| PPP |F X|Len1 | PPP | Compr | | | (20) | | Proto |F T| | Proto | header |Data| | | | Field | | Field1| | | | | | (1) |1-2 octets| (0-2) | | | +------+------+-------+----------+-------+--------+----+ |<------------- IP payload -------------------->| |<-------- Mux payload --------->| Figure 8 If the tunnel contains multiplexed traffic, multiple "PPPMux payload"s are transmitted in one IP packet. Saldana, et al. Expires September 1, 2012 [Page 12] Internet-Draft TCMTF February 2012 3. Contributing Authors Jose Ruiz-Mas University of Zaragoza Dpt. IEC Ada Byron Building Zaragoza, 50018 Spain Phone: +34 976762158 Email: jruiz@unizar.es Michael A. Ramalho Cisco Systems, Inc. 1802 Rue de la Porte Wall Township, NJ 07719-3784 US Phone: +1.732.449.5762 Email: mramalho@cisco.com 4. Acknowledgements 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. 7. References 7.1. Normative References [ECRTP] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, 2003. [ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303, 2005. Saldana, et al. Expires September 1, 2012 [Page 13] Internet-Draft TCMTF February 2012 [FLV] ISO/IEC, "FLV and F4V File Format Specification", 14496-12 MPEG-4 Part 12, 2008. [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2000. [I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 AAL", I. 363.2, 1997. [IPCP-HC] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header Compression over PPP", RFC 3544, 2003. [IPHC] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2580, 1999. [L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, 2005. [PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1661, 1994. [PPP-MUX] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", RFC 3153, 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, 2007. [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, 2003. [SCTP] Stewart, Ed., R., "Stream Control Transmission Protocol", RFC 4960, 2007. [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., and et. al., "SIP: Session Initiation Protocol", RFC 3261, 2005. [TCRTP] Thomson, B., Koren, T., and D. Wing, "Tunneling Multiplexed Compressed RTP (TCRTP)", RFC 4170, 2005. [cRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, 1999. Saldana, et al. Expires September 1, 2012 [Page 14] Internet-Draft TCMTF February 2012 7.2. Informative References [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Authors' Addresses Jose Saldana University of Zaragoza Dpt. IEC Ada Byron Building Zaragoza, 50018 Spain Phone: +34 976 762 698 Email: jsaldana@unizar.es Dan Wing Cisco Systems 771 Alder Drive San Jose, CA 95035 US Phone: +44 7889 488 335 Email: dwing@cisco.com Julian Fernandez Navajas University of Zaragoza Dpt. IEC Ada Byron Building Zaragoza, 50018 Spain Phone: +34 976 761 963 Email: navajas@unizar.es Saldana, et al. Expires September 1, 2012 [Page 15] Internet-Draft TCMTF February 2012 Muthu Arul Mozhi Perumal Cisco Systems Cessna Business Park Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Phone: +91 9449288768 Email: mperumal@cisco.com Gonzalo Camarillo Ericsson Research Jorvas, Finland Phone: Email: gonzalo.camarillo@ericsson.com Saldana, et al. Expires September 1, 2012 [Page 16]