| Transport Area Working Group | J. Saldana |
| Internet-Draft | University of Zaragoza |
| Obsoletes: 4170 (if approved) | D. Wing |
| Intended status: Best Current Practice | Cisco Systems |
| Expires: January 12, 2014 | J. Fernandez Navajas |
| University of Zaragoza | |
| Muthu. A. M. Perumal | |
| Cisco Systems | |
| F. Pascual Blanco | |
| Telefonica I+D | |
| July 11, 2013 |
Tunneling Compressed Multiplexed Traffic Flows (TCM-TF)
draft-saldana-tsvwg-tcmtf-05
Tunneling Compressed and Multiplexed Traffic Flows (TCM-TF) is a method for improving the bandwidth utilization of network segments that carry multiple flows in parallel sharing a common path. The method combines standard protocols for header compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple flows are carried over that path. The amount of packets per second can also be reduced.
This document describes the TCM-TF framework and the different options which can be used for each layer (header compression, multiplexing and tunneling).
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 January 12, 2014.
Copyright (c) 2013 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 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.
This document describes a way to combine existing protocols for header compression, multiplexing and tunneling to save bandwidth for applications that generate long-term flows of small packets.
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].
The interactivity demands of some real-time services (VoIP, videoconferencing, telemedicine, video vigilance, online gaming, etc.) require a traffic profile consisting of high rates of small packets, which are necessary in order to transmit frequent updates between the two extremes of the communication. These services also demand small network delays. In addition, some other services also use small packets, although they are not delay-sensitive (e.g., instant messaging, M2M packets sending collected data in sensor networks using wireless or satellite scenarios). For both the delay-sensitive and delay-insensitive applications, their small data payloads incur significant overhead.
When a number of flows based on small packets (small-packet flows) share the same path, bandwidth can be saved by multiplexing packets belonging to different flows. If a transmission queue has not already been formed but multiplexing is desired, it is necessary to add a multiplexing delay, which has to be maintained under some threshold if the service presents tight delay requirements.
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 illustrates the overhead problem of VoIP for two different codecs.
| IPv4 | IPv6 |
|---|---|
| IPv4+UDP+RTP: 40 bytes header | IPv6+UDP+RTP: 60 bytes header |
| G.711 at 20 ms packetization: 25% header overhead | G.711 at 20 ms packetization: 37.5% header overhead |
| G.729 at 20 ms packetization: 200% header overhead | G.729 at 20 ms packetization: 300% header overhead |
At the same time, there are many real-time applications that do not use RTP. Some of them send UDP (but not RTP) packets, e.g., First Person Shooter (FPS) online games, for which latency is very critical.
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 players are important, and can decide if they win or lose a fight.
Finally, 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]).
Other applications without delay constraints are also becoming popular (e.g., instant messaging, M2M packets sending collected data in sensor networks using wireless or satellite scenarios). The number of wireless M2M (machine-to-machine) connections is steady growing since a few years, and a share of these is being used for delay-intolerant applications, e.g., industrial SCADA (Supervisory Control And Data Acquisition), power plant monitoring, smart grids, asset tracking.
In order to mitigate the bad network efficiency of flows using small packets, the multiplexing of a number of payloads into a single packet can be considered as a solution. For example, if a single VoIP flow is considered, the number of samples included in a packet can be increased, but at the cost of adding new packetization delays.
When 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.
In addition, the headers of the original packets can be compressed to save more bandwidth, using some of the already existing header compression 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.
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. The obtained savings grow with the number of flows optimized together.
This document uses a number of terms to refer to the roles played by the entities using TCM-TF.
A packet sent by an application, belonging to a flow that can be optimized by means of TCM-TF.
A flow of native packets. It can be considered a "small-packet flow" when the vast majority of the generated packets present a low payload-to-header ratio.
A packet including a number of multiplexed and header-compressed native ones, and also a tunneling header.
A flow of TCM packets, including a number of optimized native flows.
The host where TCM optimization is deployed. It corresponds to both the ingress and the egress of the tunnel transporting the compressed and multiplexed packets.
If the optimizer compresses headers, multiplexes packets and creates the tunnel, it behaves as a "TCM-ingress optimizer", or "TCM-IO". It takes native packets or flows and "optimizes" them.
If it extracts packets from the tunnel, demultiplexes packets and decompresses headers, it behaves as a "TCM-egress optimizer", or "TCM-EO". The TCM-egress optimizer takes a TCM flow and "rebuilds" the native packets as they were originally sent.
The relationship between a pair of TCM optimizers exchanging TCM packets.
A network entity which makes the decisions about TCM-TF parameters: multiplexing period to be used, flows to be optimized together, depending on their IP addresses, ports, etc. It is connected with a number of TCM-TF optimizers, and orchestrates the optimization that takes place between them.
Different scenarios of application can be considered for the tunneling, compressing and multiplexing solution:
If we consider the residential users of a real-time interactive application (e.g., VoIP, an online game generating small packets) in a town or a district, a TCM optimizing module can be included in network devices, in order to group packets with the same destination. Depending on the number of users of the application, the packets could be grouped at different levels in DSL fixed network scenarios, at gateway level in LTE mobile network scenarios or even in other ISP edge routers. TCM-TF may also be applied for fiber residential accesses, and in 2G/3G mobile networks. This would reduce bandwidth requirements in the provider aggregation network, and in the network connection of the application provider, thus resulting in savings for both actors.
In this scenario, agreements between different companies can be established in order to save bandwidth and to reduce packets per second. For example, a service provider (e.g., an online gaming company) could be allowed to place a TCM optimizer in the aggregation network of an ISP, being able to optimize all the flows of a game or service. Another TCM optimizer would rebuild these packets once they arrive to the network of the provider.
At the same time, the ISP would implement TCM-TF capabilities within its own MPLS network in order to optimize internal network resources: optimizing modules could be embedded in the Label Edge Routers of the network. In that scenario MPLS would be the “tunneling” layer, being the tunnels the paths defined by the MPLS labels and avoiding the use of other tunneling protocols.
Finally, some networks use cRTP [cRTP] on their access links. This gives bandwidth savings on the access link, but as a counterpart it consumes considerable CPU resources on the aggregation router. In these cases, by means of TCM, instead of only saving bandwidth on the access link, it could also be saved across the core, and on the far-end access link, all without the CPU impact on the aggregation router.
End users can also optimize traffic end-to-end from network borders. As an example, we can consider the case of an enterprise with a number of distributed central offices, in which an appliance could be placed next to the access router, being able to optimize traffic flows with a shared origin and destination. Thus, a number of remote desktop sessions to the same server could be optimized, or a number of VoIP calls between two offices could also require less bandwidth and fewer packets per second.
Another example of an end user collaborating in traffic optimization could be an Internet café, which is suitable of having many users of the same application (e.g., a game) sharing the same access link. Internet cafés are very popular in countries with relatively low access speeds in households, where home computer penetration is usually low as well. In many of these countries, bandwidth can become a serious limitation for this kind of business, so TCM-TF savings may become critical for their viability.
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 maximum 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. TCM optimization of small packets into one packet for transmission would improve the efficiency. Satellite links would also find it useful to multiplex and compress small TCP packets into one packet. This could be especially interesting for compressing TCP ACKs.
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.
In a M2M/SCADA (Supervisory Control And Data Acquisition) context, TCM optimization can be applied when a satellite link is used for collecting the data of a number of sensors. M2M terminals are normally equipped with sensing devices which can interface to proximity sensor networks through wireless connections. The terminal can send the collected sensing data using a satellite link connecting to a satellite gateway, which in turn will forward the M2M/SCADA data to the to the processing and control center through Internet. The size of typical M2M application transaction depends on the specific service and it may vary from a minimum of 20 bytes (e.g., tracking and metering in private security) to about 1,000 bytes (e.g., video-surveillance). In this context, TCM-TF concepts can be also applied to allow a more efficient use of the available satellite link capacity, matching the requirements demanded by some M2M services. If the case of large sensor deployments is considered, where proximity sensor networks transmit data through different satellite terminals, the use of compression algorithms already available in current satellite systems to reduce the overhead introduced by TCP or UDP and IPv6 protocols is certainly desirable. In addition to this, tunneling and multiplexing functions available from TCM-TF allows extending compression functionality throughout the rest the network, to eventually reach the processing and control centers.
In conclusion, a standard able to compress headers, multiplex a number of packets and send them together using a tunnel, can benefit various stakeholders:
Other fact that has to be taken into account is that the technique not only saves bandwidth but also reduces the number of packets per second, which sometimes can be a bottleneck for a satellite link or even for a network router.
The current standard [TCRTP] defines a way to reduce bandwidth and pps of RTP traffic, by combining three different standard protocols:
The three layers are combined as shown in the
RTP/UDP/IP | | ---------------------------- | ECRTP compressing layer | | ---------------------------- | PPPMUX multiplexing layer | | ---------------------------- | L2TP tunneling layer | | ---------------------------- | IP
Figure 1
In contrast to the current standard [TCRTP], TCM-TF allows other header compression protocols in addition to RTP/UDP, since services based on small packets also use by bare UDP or TCP, as shown in Figure 2:
TCP/IP UDP/IP RTP/UDP/IP
\ | /
\ | / ------------------------------
\ | /
Nothing or ROHC or ECRTP or IPHC header compressing layer
|
| ------------------------------
|
PPPMUX or other mux protocols multiplexing layer
|
/ \ ------------------------------
/ \
/ \
GRE or L2TP \ tunneling layer
| MPLS
| ------------------------------
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 proposal:
It can be observed that TCRTP [TCRTP] is included as an option in TCM-TF, combining [ECRTP], [PPP-MUX] and [L2TPv3].
Payload compression schemes could also be used, but they are not the aim of this document.
This section describes how to combine protocols belonging to trhee layers (compressing, multiplexing, and tunneling), in order to save bandwidth for the considered flows.
TCM-TF can be implemented in different ways. The most straightforward is to implement it in the devices terminating the flows (these devices can be e.g., voice gateways, or proxies grouping a number of flows):
[ending device]---[ending device]
^
|
TCM-TF over IP
Figure 3
Another way TCM-TF 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 TCM-TF sessions without the participation of the endpoints that generate the flows (Figure 4).
[ending device]\ /[ending device]
[ending device]---[concentrator]---[concentrator]---[ending device]
[ending device]/ \[ending device]
^ ^ ^
| | |
Native IP TCM-TF over IP Native IP
Figure 4
A number of already compressed flows can also be merged in a tunnel using a concentrator in order to increase the number of flows in a tunnel (Figure 5):
[ending device]\ /[ending device]
[ending device]---[concentrator]---[concentrator]---[ending device]
[ending device]/ \[ending device]
^ ^ ^
| | |
Compressed TCM-TF over IP Compressed
Figure 5
There are different protocols that can be used for compressing IP flows:
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.
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 Header checksum described in [ECRTP].
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.
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 TCM-TF.
When header compression is used inside a tunnel, it reduces the size of the headers of the IP packets 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).
By multiplexing multiple small payloads in a single tunneled packet, reasonable bandwidth efficiency can be achieved, since the tunnel overhead is shared by multiple packets belonging to the flows active between the source and destination of an L2TP tunnel. The packet size of the flows has to be small in order to permit good bandwidth savings.
If the source and destination of the tunnel are the same as the source and destination of the compressing protocol sessions, then the source and destination must have multiple active small-packet flows to get any benefit from multiplexing.
Because of this, TCM-TF is mostly useful for applications where many small-packet flows run between a pair of hosts. The number of simultaneous sessions required to reduce the header overhead to the desired level depends on the average payload size, and also on the size of the tunnel header. A smaller tunnel header will result in fewer simultaneous sessions being required to produce adequate bandwidth efficiencies.
Different tunneling schemes can be used for sending end to end the compressed payloads.
L2TP tunnels should be used to tunnel the compressed 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 TCM-TF.
In some scenarios, mainly in operator´s core networks, the use of MPLS is widely deployed as data transport method. The adoption of MPLS as tunneling layer in this proposal intends to natively adapt TCM-TF to those transport networks.
In the same way that layer 3 tunnels, MPLS paths, identified by MPLS labels, established between Label Edge Routers (LSRs), could be used to transport the compressed payloads within an MPLS network. This way, multiplexing layer must be placed over MPLS layer. Note that, in this case, layer 3 tunnel headers do not have to be used, with the consequent data efficiency improvement.
The packet format for a packet compressed is:
+------------+-----------------------+
| | |
| 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 TCM-TF with a single payload is all of the above packets concatenated. Here is an example with one payload, using L2TP or GRE tunneling:
+------+------+-------+----------+-------+--------+----+
| 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 tunneling technology is MPLS, then the scheme would be:
+------+-------+----------+-------+--------+----+
|MPLS | Mux |P L| | | | |
|header| PPP |F X|Len1 | PPP | Compr | |
| | Proto |F T| | Proto | header |Data|
| | Field | | Field1| | |
| | (1) |1-2 octets| (0-2) | | |
-+------+-------+----------+-------+--------+----+
|<---------- MPLS payload -------------->|
|<-------- Mux payload --------->|
Figure 9
If the tunnel contains multiplexed traffic, multiple "PPPMux payload"s are transmitted in one IP packet.
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
Email: Gonzalo.Camarillo@ericsson.com
Michael A. Ramalho Cisco Systems, Inc. 8000 Hawkins Road Sarasota, FL 34241-9300 US Phone: +1.732.832.9723 Email: mramalho@cisco.com
Jose Ruiz Mas University of Zaragoza Dpt. IEC Ada Byron Building 50018 Zaragoza Spain Phone: +34 976762158 Email: jruiz@unizar.es
Diego Lopez Garcia Telefonica I+D Ramon de la cruz 84 28006 Madrid Spain Phone: +34 913129041 Email: diego@tid.es
David Florez Rodriguez Telefonica I+D Ramon de la cruz 84 28006 Madrid Spain Phone: +34 91312884 Email: dflorez@tid.es
Manuel Nunez Sanz Telefonica I+D Ramon de la cruz 84 28006 Madrid Spain Phone: +34 913128821 Email: mns@tid.es
Juan Antonio Castell Lucia Telefonica I+D Ramon de la cruz 84 28006 Madrid Spain Phone: +34 913129157 Email: jacl@tid.es
Mirko Suznjevic University of Zagreb Faculty of Electrical Engineering and Computing, Unska 3 10000 Zagreb Croatia Phone: +385 1 6129 755 Email: mirko.suznjevic@fer.hr
This memo includes no request to IANA.
The most straightforward option for securing a number of non-secured flows sharing a path is by the use of IPsec [IPsec], when TCM using an IP tunnel is employed. Instead of adding a security header to the packets of each native flow, and then compressing and multiplexing them, a single IPsec tunnel can be used in order to secure all the flows together, thus achieving a higher efficiency. This use of IPsec protects the packets only within the transport network between tunnel ingress and egress and therefore does not provide end-to-end authentication or encryption. In some cases , e.g., where the end points are trusted, this model may be appropriate.
When a number of already secured flows including ESP [ESP] headers are optimized by means of TCM, and the addition of further security is not necessary, their ESP/IP headers can still be compressed using suitable algorithms [RFC5225], in order to improve the efficiency. This header compression does not change the end-to-end security model.
Future versions of this document will consider whether some TCM-TF mechanisms could be potentially exploited in order to deploy or amplify DoS attacks against network infrastructure. Solutions will be provided if potential attacks are identified.