< draft-suznjevic-tsvwg-mtd-tcmtf-02.txt   draft-suznjevic-tsvwg-mtd-tcmtf-03.txt >
Transport Area Working Group M. Suznjevic Transport Area Working Group M. Suznjevic
Internet-Draft University of Zagreb Internet-Draft University of Zagreb
Intended status: Informational J. Saldana Intended status: Informational J. Saldana
Expires: June 17, 2014 University of Zaragoza Expires: December 12, 2014 University of Zaragoza
December 14, 2013 June 10, 2014
Delay Limits and Multiplexing Policies to be employed with Tunneling Delay Limits and Multiplexing Policies to be employed with Tunneling
Compressed Multiplexed Traffic Flows Compressed Multiplexed Traffic Flows
draft-suznjevic-tsvwg-mtd-tcmtf-02 draft-suznjevic-tsvwg-mtd-tcmtf-03
Abstract Abstract
This document contains recommendations to be taken into account when This document contains recommendations to be taken into account when
using methods which optimize bandwidth utilization through using methods which optimize bandwidth utilization through
compression, multiplexing, and tunneling traffic flows (TCM-TF) over compression, multiplexing, and tunneling traffic flows (TCM-TF) over
a network path. Different multiplexing policies and implementation a network path. Different multiplexing policies and implementation
issues which are service and link specific are discussed. issues which are service and link specific are discussed.
Additionally, this document describes policies which can be used for Additionally, this document describes policies which can be used for
detecting, classifying, and choosing the network flows suitable for detecting, classifying, and choosing the network flows suitable for
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 17, 2014. This Internet-Draft will expire on December 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Considered services . . . . . . . . . . . . . . . . . . . . . 4 3. Considered services . . . . . . . . . . . . . . . . . . . . . 4
3.1. Real-time services . . . . . . . . . . . . . . . . . . . 4 3.1. Real-time services . . . . . . . . . . . . . . . . . . . 4
3.2. Non real-time services . . . . . . . . . . . . . . . . . 4 3.2. Non real-time services . . . . . . . . . . . . . . . . . 5
4. Multiplexing policies in TCM-TF . . . . . . . . . . . . . . . 5 4. Multiplexing policies in TCM-TF . . . . . . . . . . . . . . . 5
5. Detecting, classifying, and choosing network flows to be 5. Detecting, classifying, and choosing network flows to be
optimized . . . . . . . . . . . . . . . . . . . . . . . . . . 6 optimized . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Optimization within an administrative domain . . . . . . 6 5.1. Optimization within an administrative domain . . . . . . 6
5.2. Optimization based on statistics . . . . . . . . . . . . 7 5.2. Optimization based on statistics . . . . . . . . . . . . 7
6. Delay recommendations . . . . . . . . . . . . . . . . . . . . 8 6. Delay recommendations . . . . . . . . . . . . . . . . . . . . 8
6.1. VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Online games . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Online games . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Remote desktop access . . . . . . . . . . . . . . . . . . 13 6.3. Remote desktop access . . . . . . . . . . . . . . . . . . 13
6.4. Non real-time service . . . . . . . . . . . . . . . . . . 13 6.4. Non real-time service . . . . . . . . . . . . . . . . . . 13
skipping to change at page 12, line 13 skipping to change at page 12, line 13
listed real-time network services. listed real-time network services.
6.1. VoIP 6.1. VoIP
For conversational audio, the International Telecommunication Union For conversational audio, the International Telecommunication Union
recommends [ITU-T_G.114] less than 150 millisecond one-way end-to-end 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 delay for high-quality real time traffic, but delays between 150 ms
and 400 ms are acceptable. When considering conversational audio it and 400 ms are acceptable. When considering conversational audio it
should be noted that this delay limits include jitter buffers and should be noted that this delay limits include jitter buffers and
codec processing. For streaming audio, delay constraints are much codec processing. For streaming audio, delay constraints are much
looser, the delay should be less than 10 s [ITU-T_G.1010]. looser, the delay should be less than 10 s [ITU-T_G.1010]. Tunneling
Multiplexed Compressed RTP (TCRTP) [RFC4170] already considers
tunneling, compressing and multiplexing VoIP packets.
6.2. Online games 6.2. Online games
Online games comprise game genres which have different latency Online games comprise game genres which have different latency
requirements. This draft focuses on real-time online games and requirements. This draft focuses on real-time online games and
endorses the general game categorization proposed in endorses the general game categorization proposed in
[Claypool_Latency] in which online games have been divided into: [Claypool_Latency] in which online games have been divided into:
o Omnipresent, with the threshold of acceptable latency (i.e., o Omnipresent, with the threshold of acceptable latency (i.e.,
latency in which performance is above 75% of the unimpaired latency in which performance is above 75% of the unimpaired
skipping to change at page 13, line 7 skipping to change at page 13, line 11
"unimpaired". Besides service QoE, it has been shown that delay has "unimpaired". Besides service QoE, it has been shown that delay has
great impact on the user's decision to join a game, but significantly great impact on the user's decision to join a game, but significantly
less on the decision to leave the game [Henderson_QoS]. less on the decision to leave the game [Henderson_QoS].
A study on Mean Opinion Score (MOS) evaluation, based on variation of A study on Mean Opinion Score (MOS) evaluation, based on variation of
delay and jitter for MMORPGs, suggested that MOS drops below 4 for delay and jitter for MMORPGs, suggested that MOS drops below 4 for
delays greater than 120 ms [Ries_QoEMMORPG]. The MOS score of 5 delays greater than 120 ms [Ries_QoEMMORPG]. The MOS score of 5
indicates excellent quality, while MOS score of 1 indicates bad indicates excellent quality, while MOS score of 1 indicates bad
quality. Another study focused on extracting the duration of play quality. Another study focused on extracting the duration of play
sessions for MMORPGs from the network traffic traces showed that the sessions for MMORPGs from the network traffic traces showed that the
session durations start to decline sharply when latency is between session durations start to decline sharply when round trip time is
150 ms and 200 ms [Chen_HowSensitive]. between 150 ms and 200 ms [Chen_HowSensitive].
While original classification work [Claypool_Latency] states that While original classification work [Claypool_Latency] states that
latency up to 1 second is tolerated by omnipresent games, other latency up to 1 second is tolerated by omnipresent games, other
studies argued that only latency up to 200 ms is tolerated by players studies argued that only latency up to 200 ms is tolerated by players
of RTS games [Cajada_RTS]. of RTS games [Cajada_RTS].
6.3. Remote desktop access 6.3. Remote desktop access
For the remote computer access services, the delays are dependent on For the remote computer access services, the delays are dependent on
the task performed through the remote desktop. Tasks may include the task performed through the remote desktop. Tasks may include
skipping to change at page 13, line 32 skipping to change at page 13, line 36
[Dusi_Thin]. [Dusi_Thin].
6.4. Non real-time service 6.4. Non real-time service
Traffic flows of several types of non real-time services can be Traffic flows of several types of non real-time services can be
optimized using TCM-TF. Under this category we include services for optimized using TCM-TF. Under this category we include services for
M2M metering information, streaming audio, and instant messaging. M2M metering information, streaming audio, and instant messaging.
M2M metering services are suitable for TCM-TF optimization not only M2M metering services are suitable for TCM-TF optimization not only
due to their very loose delay requirements, but also because of the due to their very loose delay requirements, but also because of the
one way nature of the communication (i.e., most information travels one way nature of the communication (i.e., most information travels
from sensors to the central server) [Liu_M2M]. Instant messaging from sensors to the central server) [Liu_M2M]. The signalling
(despite "instant" in its name) has been categorized as data service information related to M2M can also be optimized. Internet of Things
by the ITU-T, and it has been designated with acceptable delays of up application layer protocols such as CoAP [CoAP], used in Constrained
to a few seconds [ITU-T_G.1010]. RESTful Environments (CoRE)[RFC6690], work over UDP and send small
packets. The ACK_TIMEOUT period in CoAP is set to 2 seconds.
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 6.5. Summary
We group all the results in the Table 1 indicating the maximum We group all the results in the Table 1 indicating the maximum
allowed latency and proposed multiplexing periods. Proposed allowed latency and proposed multiplexing periods. Proposed
multiplexing periods are guidelines, since the exact values are multiplexing periods are guidelines, since the exact values are
dependant of the existing delay in the network. It should be noted dependant of the existing delay in the network. It should be noted
that reported tolerable latency is based on values of preferred that reported tolerable latency is based on values of preferred
delays, and delays in which QoE estimation is not significantly delays, and delays in which QoE estimation is not significantly
degraded. Multiplexing periods of about 1 second can be considered degraded. Multiplexing periods of about 1 second can be considered
skipping to change at page 15, line 18 skipping to change at page 15, line 26
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999. Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3393] Demichelis, C., Chimento, S., and P. Zekauskas, "IP Packet [RFC3393] Demichelis, C., Chimento, S., and P. Zekauskas, "IP Packet
Delay Variation Metric for IP Performance Metrics (IPPM)", Delay Variation Metric for IP Performance Metrics (IPPM)",
RFC 3393, November 2002. RFC 3393, November 2002.
[RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling
Multiplexed Compressed RTP (TCRTP)", RFC 6690, November
2005.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", RFC 6390, October 2011. Performance Metric Development", RFC 6390, October 2011.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012.
10.2. Informative References 10.2. Informative References
[Cajada_RTS] [Cajada_RTS]
Cajada, M., "VFC-RTS: Vector-Field Consistency para Real- Cajada, M., "VFC-RTS: Vector-Field Consistency para Real-
Time-Strategy Multiplayer Games", Master of Science Time-Strategy Multiplayer Games", Master of Science
Disertation , 2012. Disertation , 2012.
[Chen_HowSensitive] [Chen_HowSensitive]
Chen, K., Huang, P., and L. Chin-Luang, "How sensitive are Chen, K., Huang, P., and L. Chin-Luang, "How sensitive are
online gamers to network quality?", Communications of the online gamers to network quality?", Communications of the
ACM 49, 2006. ACM 49, 2006.
[Claypool_Latency] [Claypool_Latency]
Claypool, M. and K. Claypool, "Latency and player actions Claypool, M. and K. Claypool, "Latency and player actions
in online games", Communications of the ACM 49, 2006. in online games", Communications of the ACM 49, 2006.
[CoAP] Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", Internet-Draft Jun, 2013.
[Dick_Analysis] [Dick_Analysis]
Dick, M., Wellnitz, O., and L. Wolf, "Analysis of factors Dick, M., Wellnitz, O., and L. Wolf, "Analysis of factors
affecting players' performance and perception in affecting players' performance and perception in
multiplayer games", Proceedings of 4th ACM SIGCOMM multiplayer games", Proceedings of 4th ACM SIGCOMM
workshop on Network and system support for games, pp. 1 - workshop on Network and system support for games, pp. 1 -
7 , 2005. 7 , 2005.
[Dusi_Thin] [Dusi_Thin]
Dusi, M., Napolitano, S., Niccolini, S., and S. Longo, "A Dusi, M., Napolitano, S., Niccolini, S., and S. Longo, "A
Closer Look at Thin-Client Connections: Statistical Closer Look at Thin-Client Connections: Statistical
 End of changes. 11 change blocks. 
13 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/