Transport Area Working Group M. Suznjevic Internet-Draft University of Zagreb Intended status: Informational J. Saldana Expires: December 16, 2013 University of Zaragoza June 14, 2013 Delay Limits and Multiplexing Policies to be employed with Tunneling Compressed Multiplexed Traffic Flows draft-suznjevic-tsvwg-mtd-tcmtf-01 Abstract This document contains recommendations to be taken into account when using methods which optimize bandwidth utilization through compression, multiplexing, and tunneling traffic flows (TCMTF) over a network path. Different multiplexing policies and implementation issues which are service and link specific are discussed. Additionally, this document describes policies which can be used for detecting, classifying, and choosing the network flows suitable for optimization by using TCMTF. Finally, recommendations of maximum tolerable delays to be added by optimization techniques are reported. Recommendations are presented only for network services for which such bandwidth optimization techniques are applicable (i.e., services with low payload to header size ratio, which will also be denoted as "small-packet flows"). 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 December 16, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Suznjevic & Saldana Expires December 16, 2013 [Page 1] Internet-Draft Delay Limits and Policies for TCMTF June 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Considered services . . . . . . . . . . . . . . . . . . . . . 4 3.1. Real-time services . . . . . . . . . . . . . . . . . . . 4 3.2. Non real-time services . . . . . . . . . . . . . . . . . 4 4. Multiplexing policies in TCMTF . . . . . . . . . . . . . . . 5 5. Detecting, classifying, and choosing network flows to be optimized . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Optimization within an administrative domain . . . . . . 6 5.2. Optimization based on statistics . . . . . . . . . . . . 7 6. Delay recommendations . . . . . . . . . . . . . . . . . . . . 8 6.1. VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Online games . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Remote desktop access . . . . . . . . . . . . . . . . . . 13 6.4. Non real-time service . . . . . . . . . . . . . . . . . . 13 6.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document extends the draft [TCMTF] with a set of recommendations regarding the processes of compression, multiplexing, and tunneling. These recommendations are needed because the techniques proposed in [TCMTF], while saving bandwidth, may cause network impairments. Network delay is one of the main factors which can degrade the Quality of Experience (QoE) of real-time network services RFC 6390 [RFC6390] [TGPP_TR26.944]. In order to prevent the perceived quality degradation of the services when using TCMTF, a policy defining a multiplexing period can be employed. First, the document describes different multiplexing policies which can be employed for defining which native packets are multiplexed Suznjevic & Saldana Expires December 16, 2013 [Page 2] Internet-Draft Delay Limits and Policies for TCMTF June 2013 together. A policy combining a multiplexing period and a packet size limit is proposed in order to put an upper bound on the added delay. Additionally, this document describes the policies that can be employed for detecting, classifying, and choosing the network flows suitable for TCMTF optimization. Finally, values for maximum tolerable delays presented here from the base of the proposed multiplexing policy. The recommendations are presented for both real-time and non real-time network services in which TCMTF bandwidth optimization is applicable (i.e., services which have low payload-to-header-size ratio, which results in high protocol overhead, which will also be denoted as small-packet flows). 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]. 2. Terminology This document uses a number of terms to refer to the roles played by participants in, and objects of, the TCMTF sessions. multiplexer The host where TCMTF optimization is deployed. It corresponds to the ingress of the tunnel where native packets are included. demultiplexer The host where TCMTF multiplexed packets are received and rebuilt to their native form. It corresponds to the tunnel egress. policy manager A network entity which makes the decisions about TCMTF parameters: multiplexing period; flows to be multiplexed together, depending on their IP addresses, ports, etc. It is connected with a number of TCMTF multiplexers and demultiplexers, and orchestrates the optimization that takes place between them. native packet A packet sent by an application, belonging to a flow that can be optimized by means of TCMTF. Suznjevic & Saldana Expires December 16, 2013 [Page 3] Internet-Draft Delay Limits and Policies for TCMTF June 2013 multiplexed packet A packet including a number of multiplexed and header-compressed native ones, and also a tunneling header shared by all the packets, as detailed by TCMTF. 3. Considered services The services considered suitable for being optimized by TCMTF are those that generate long-term flows of small packets, with a low payload to header size ratio. Some real-time and some non real-time services are suitable for optimization by means of TCMTF. 3.1. Real-time services Under the term "real-time network services" we consider both conversational and streaming service classes as defined in [TGPP_TS]. Interactive and background services are considered non real-time. Fundamental requirements of real-time network services include conversational pattern (stringent and low delay) and preservation of the time relation (variation) between the information entities of the stream. We identify the following real-time network services with low payload to header size ratio as candidates for the bandwidth optimization techniques presented in TCMTF: o Voice over IP o Online games o Remote desktop services While video services are considered real-time, they are not suitable for bandwidth optimization techniques proposed in [TCMTF], due to their high payload to header size ratio. Due to the same reason, we do not take into account cloud gaming services. In such gaming services all the calculations of the game state are deployed at the server and a real-time video stream is sent to the client. In these cases, TCMTF optimization is neither interesting nor applicable. 3.2. Non real-time services On the other hand, TCMTF can be applied for some non real-time services such as streaming audio, web browsing, and instant messaging. These applications are suitable for TCMTF in terms of payload to header size ratio, but different studies have shown that acceptable delays for these services are up to several seconds Suznjevic & Saldana Expires December 16, 2013 [Page 4] Internet-Draft Delay Limits and Policies for TCMTF June 2013 [ITU-T_G.1010]. Also, some types of machine to machine (M2M) traffic (e.g., metering messages from various sensors) may have traffic properties suitable for TCMTF. Acceptable delays for these services can be go up to an hour [Liu_M2M]. We list limitations for these services as well, although in the practical application TCMTF should not introduce delays which would be noticeable in comparison with delays of such magnitude (i.e., seconds and more). 4. Multiplexing policies in TCMTF A multiplexing policy defines the decision process for determining which native packet goes in which multiplexed packet. The policies proposed for TCMTF are: o Fixed number of packets - once a fixed number of packets (N) has arrived, a multiplexed packet is created and sent. o Size limit - once a size limit is reached (e.g., next to the MTU of the underlying network), a multiplexed packet is sent. o Period - a multiplexed packet is sent every time period T. o Timeout - sends a multiplexed packet if a native one arrives and the time since the last multiplexed packet departure is above a defined timeout value. Only the two latter policies are able to control the additional delay introduced by multiplexing. In addition, different policies can be combined. In this document we focus on the combination of "size limit" and "period" policies, as shown in Figure 1. A multiplexed packet is sent at the end of each "period". However, if the size limit is reached, then a multiplexed packet is sent immediately, and the period is "reset". Thus, the added delay is for the worst case scenario equal to the defined period. Suznjevic & Saldana Expires December 16, 2013 [Page 5] Internet-Draft Delay Limits and Policies for TCMTF June 2013 native traffic: |<--P-->|<--P-->|<--P-->|<--P-->|<-t*->|<--P-->| | | | | | | | |# # | # # | | # #|######| # #| -------------------------------------------------------> t multiplexed traffic: | | | | | | | | |# |# | |# |## |# | |# |# | |# |## |# -------------------------------------------------------> t * period reset (tR ^ | | | | | | |transac. total RTT | | | | | -------S v | | ------- | ^ | | ------- | | | | ------- |transf. | | ------- | | | R<------ | v v | | S: Packet sent R: Packet received Figure 2 Suznjevic & Saldana Expires December 16, 2013 [Page 9] Internet-Draft Delay Limits and Policies for TCMTF June 2013 Figure 2 illustrates these delays. The labeled times (S and R) designate the times in which the packet is sent and received, respectively, by the network card interface. The use of TCMTF requires the addition of a multiplexer and a demultiplexer in the scenario. A number of flows are multiplexed together before being sent through the network. The packets are demultiplexed and rebuilt before being forwarded to the application server. A scheme of TCMTF is included in Figure 3: +--------+ |client 1|___ +--------+ \ \ _ _ +--------+ +-----+ ( ` )_ +-------+ +------+ |client 2|--->| mux |--> ( ) `) --->| demux |-->|server| +--------+ +-----+ (_ (_ . _) _) +-------+ +------+ / Internet / +--------+ / <-----------tcmtf-----------> |client n|_/ +--------+ Figure 3 This technique groups packets in order to build a multiplexed one. As previously stated, the focus of this document is on "multiplexing period" policy for creating the multiplexed packet combined with size limit policy. Multiplexing period is a time frame in which the multiplexer waits for native packets to arrive in order to send them as one multiplexed packet. If the multiplexed packet size limit is reached before the multiplexing period has run out (i.e., if enough native packets arrive to fill the limit), the multiplexed packet is sent right away. In this way a certain amount of delay caused by the TCMTF optimization is added in the communication. It is important to emphasize that multiplexing delay can't exceed the multiplexing period, and that it will only reach the value of multiplexing period on a link with a low traffic load. Multiplexing delay can be classified as caused by the middlebox presence as defined in RFC 6390 RFC 6390 [RFC6390]. The delay in the multiplexer includes the time during which the packets are retained until the bundled packet is sent, plus processing time. In the demultiplexer however, the packets are not retained, so only the processing time is considered. Figure 4 shows the total delay, when a multiplexer and a demultiplexer are added. It should be noted that multiplexing can be deployed independently in both directions, or only in one of them. Suznjevic & Saldana Expires December 16, 2013 [Page 10] Internet-Draft Delay Limits and Policies for TCMTF June 2013 +---------+ +--------+ +--------+ +---------+ | Host 1 | | mux | | demux | | Host 2 | +---------+ +--------+ +--------+ +---------+ S------- | | | ^ ^ | ------- | | | | | | --R ^ | | | | | | | | | | | | | mux | | | | | | | | | | | | | | | | transf. | | S---- v | | (& mux) | | | ------- | | | | | ----R ^ | | | | | demux | | total RTT | | | | | | | S--- v | v | | | --------->R ^ | | | | | | |transac. | | | | | | --------S v | | -------- | ^ | | -------- | | | | -------- | transf. | | ------- | | | R<------ | v v | | S: Packet sent R: Packet received Figure 4 With respect to efficiency in terms of use of the bandwidth, a tradeoff appears: the longer the multiplexing period, the higher the number of packets which can be grouped, thus obtaining better bandwidth savings. So in order to calculate the maximum multiplexing period, the rest of the delays have to be considered: if the sum of transaction, and transfer delays is under the maximum tolerable delay, then multiplexing will be possible without harming the user experience. The overall delay may be calculated according to the ITU-T Y.1541 recommendation [ITU-T_Y.1541]. Subtracting propagation, processing, and transmission delay from the tolerable delay for specific service results in the maximum value of the multiplexing period. Next, we will report the maximum tolerable latency for the previously listed real-time network services. Suznjevic & Saldana Expires December 16, 2013 [Page 11] Internet-Draft Delay Limits and Policies for TCMTF June 2013 6.1. VoIP For conversational audio, the International Telecommunication Union recommends [ITU-T_G.114] less than 150 millisecond one-way end-to-end delay for high-quality real time traffic, but delays between 150 ms and 400 ms are acceptable. When considering conversational audio it should be noted that this delay limits include jitter buffers and codec processing. For streaming audio, delay constraints are much looser, the delay should be less than 10 s [ITU-T_G.1010]. 6.2. Online games Online games comprise game genres which have different latency requirements. This draft focuses on real-time online games and endorses the general game categorization proposed in [Claypool_Latency] in which online games have been divided into: o Omnipresent, with the threshold of acceptable latency (i.e., latency in which performance is above 75% of the unimpaired performance) of 1000 ms. The most representative genre of omnipresent games are Real-Time Strategies. o Third Person Avatar, with the threshold of acceptable latency of 500 ms. These games include Role Playing Games (RPG) and Massively Multiplayer Online Role-Playing Games (MMORPG). o First Person Avatar, in which threshold of acceptable latency is 100 ms. The most popular subgenre of them are First Person Shooters, such as "Call of Duty" or "Halo" series. The study [Claypool_Latency] evaluated players' performance in certain tasks, while increasing latency, and reported values at which the performance dropped below 75% of the performance under unimpaired network conditions. While measuring objective performance metrics, this method highly underestimates the impact of delays on players' QoE. Further studies accessing a particular game genre reported much lower latency thresholds for unimpaired gameplay. A survey using a large number of First Person Shooter games has been carried out in [Dick_Analysis]. They state that latency about 80 ms could be considered as acceptable, since the games have been rated as "unimpaired". Besides service QoE, it has been shown that delay has great impact on the user's decision to join a game, but significantly less on the decision to leave the game [Henderson_QoS]. A study on Mean Opinion Score (MOS) evaluation, based on variation of delay and jitter for MMORPGs, suggested that MOS drops below 4 for delays greater than 120 ms [Ries_QoEMMORPG]. The MOS score of 5 Suznjevic & Saldana Expires December 16, 2013 [Page 12] Internet-Draft Delay Limits and Policies for TCMTF June 2013 indicates excellent quality, while MOS score of 1 indicates bad quality. Another study focused on extracting the duration of play sessions for MMORPGs from the network traffic traces showed that the session durations start to decline sharply when latency is between 150 ms and 200 ms [Chen_HowSensitive]. While original classification work [Claypool_Latency] states that latency up to 1 second is tolerated by omnipresent games, other studies argued that only latency up to 200 ms is tolerated by players of RTS games [Cajada_RTS]. 6.3. Remote desktop access For the remote computer access services, the delays are dependent on the task performed through the remote desktop. Tasks may include operations whith audio, video and data (e.g., reading, web browsing, document creation). A QoE study indicates that for audio latency below 225 ms and for data latency below 200 ms is tolerated [Dusi_Thin]. 6.4. Non real-time service Traffic flows of several types of non real-time services can be optimized using TCMTF. Under this category we include services for M2M metering information, streaming audio, instant messaging, and web browsing. M2M metering services are suitable for TCMTF optimization not only due to their very loose delay requirements, but also because of the one way nature of the communication (i.e., most information travels from sensors to the central server) [Liu_M2M]. Instant messaging (despite "instant" in its name) has been categorized as data service by the ITU-T, and it has been designated with acceptable delays of up to a few seconds [ITU-T_G.1010]. 6.5. Summary We group all the results in the Table 1 indicating the maximum allowed latency and proposed multiplexing periods. Proposed multiplexing periods are guidelines, since the exact values are dependant of the existing delay in the network. It should be noted that reported tolerable latency is based on values of preferred delays, and delays in which QoE estimation is not significantly degraded. Multiplexing periods of about 1 second can be considered as sufficient for non real-time services (e.g., web browsing and streaming audio). Suznjevic & Saldana Expires December 16, 2013 [Page 13] Internet-Draft Delay Limits and Policies for TCMTF June 2013 +---------------------------+-----------------------+---------------+ | Service | Tolerable latency | Mux. period | | | (OWD) | | +---------------------------+-----------------------+---------------+ | Voice communication | < 150ms | < 30ms | | Omnipresent games | < 300ms | < 60ms | | First person avatar games | < 80ms | < 15ms | | Third person avatar games | < 120ms | < 25ms | | Remote desktop | < 200ms | < 40ms | | Web browsing | < 2s | < 400ms | | Instant messaging | < 5s | < 1s | | M2M (metering) | < 1hour | < 1s | +---------------------------+-----------------------+---------------+ Table 1: Final recommendations 7. Acknowledgements 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations No relevant security considerations have been identified 10. References 10.1. Normative References [ITU-T_G.1010] International Telecommunication Union-Telecommunication, "End-user multimedia QoS categories ", SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS; Quality of service and performance , 2001. [ITU-T_G.114] ITU-T, "ITU-T Recommendation G.114 One-way transmission time", ITU G.114, 2003. [ITU-T_Y.1541] International Telecommunication Union-Telecommunication, "; Network performance objectives for IP-based services ", SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS; Internet protocol aspects - Quality of service and network performance , 2011. Suznjevic & Saldana Expires December 16, 2013 [Page 14] Internet-Draft Delay Limits and Policies for TCMTF June 2013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3393] Demichelis, C., Chimento, S., and P. Zekauskas, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) ", RFC 3393, November 2002. [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", RFC 6390, October 2011. 10.2. Informative References [Cajada_RTS] Cajada, M., "VFC-RTS: Vector-Field Consistency para Real- Time-Strategy Multiplayer Games", Master of Science Disertation , 2012. [Chen_HowSensitive] Chen, K., Huang, P., and L. Chin-Luang, "How sensitive are online gamers to network quality?", Communications of the ACM 49, 2006. [Claypool_Latency] Claypool, M. and K. Claypool, "Latency and player actions in online games", Communications of the ACM 49, 2006. [Dick_Analysis] Dick, M., Wellnitz, O., and L. Wolf, "Analysis of factors affecting players' performance and perception in multiplayer games", Proceedings of 4th ACM SIGCOMM workshop on Network and system support for games, pp. 1 - 7 , 2005. [Dusi_Thin] Dusi, M., Napolitano, S., Niccolini, S., and S. Longo, "A Closer Look at Thin-Client Connections: Statistical Application Identification for QoE Detection", IEEE Communications Magazine, pp. 195 - 202 , 2012. [Han_GameClassification] Suznjevic & Saldana Expires December 16, 2013 [Page 15] Internet-Draft Delay Limits and Policies for TCMTF June 2013 Han, Y-T. and H-S. Park, "Game Traffic Classification Using Statistical Characteristics at the Transport Layer", ETRI Journal pp. 22 - 32 32, 2010. [Henderson_QoS] Henderson, T. and S. Bhatti, "Networked games: a QoS- sensitive application for QoS-insensitive users?", Proceedings of the ACM SIGCOMM workshop on Revisiting IP QoS: What have we learned, why do we care?, pp. 141-147 , 2003. [Liu_M2M] Liu, R., Wu, W., Zao, H., and D. Yang, "M2M-Oriented QoS Categorization in Cellular Network", Master of Science Disertation , 2012. [Nguyen_TCSurvey] Nguyen, T. and G. Armitage, "A Survey of Techniques for Internet Traffic Classification using Machine Learning", IEEE Communications Surveys and Tutorials pp. 56 - 76. 10, 2008. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [Ries_QoEMMORPG] Ries, M., Svoboda, P., and M. Rupp, "Empirical Study of Subjective Quality for Massive Multiplayer Games", Proceedings of the 15th International Conference on Systems, Signals and Image Processing, pp.181 - 184 , 2008. [TCMTF] Saldana, J., Wing, D., Fernandez Navajas, J., Perumal, M., and F. Pascual Blanco, "Tunneling Compressed Multiplexed Traffic Flows (TCMTF)", Internet-Draft Jul, 2012. [TGPP_TR26.944] 3rd Generation Partnership Project;, "Technical Specification Group Services and System Aspects; End-to- end multimedia services performance metrics ", 3GPP TR 26.944 version 9.0.0 , 2012. [TGPP_TS] 3rd Generation Partnership Project, European Telecommunications Standards Institute, "Quality of Service (QoS) concept and architecture", 3GPP TS 23.107 version 11.0.0 Release 11 , 2012. Suznjevic & Saldana Expires December 16, 2013 [Page 16] Internet-Draft Delay Limits and Policies for TCMTF June 2013 Authors' Addresses Mirko Suznjevic University of Zagreb Faculty of Electrical Engineering and Computing, Unska 3 Zagreb 10000 Croatia Phone: +385 1 6129 755 Email: mirko.suznjevic@fer.hr Jose Saldana University of Zaragoza Dpt. IEC Ada Byron Building Zaragoza 50018 Spain Phone: +34 976 762 698 Email: jsaldana@unizar.es Suznjevic & Saldana Expires December 16, 2013 [Page 17]