Delay Limits and Multiplexing Policies to be employed with Tunneling Compressed Multiplexed Traffic Flows
draft-suznjevic-tsvwg-mtd-tcmtf-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Mirko Suznjevic , Jose Saldana | ||
| Last updated | 2014-06-10 | ||
| Replaced by | draft-suznjevic-dispatch-delay-limits | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-suznjevic-tsvwg-mtd-tcmtf-03
Transport Area Working Group M. Suznjevic
Internet-Draft University of Zagreb
Intended status: Informational J. Saldana
Expires: December 12, 2014 University of Zaragoza
June 10, 2014
Delay Limits and Multiplexing Policies to be employed with Tunneling
Compressed Multiplexed Traffic Flows
draft-suznjevic-tsvwg-mtd-tcmtf-03
Abstract
This document contains recommendations to be taken into account when
using methods which optimize bandwidth utilization through
compression, multiplexing, and tunneling traffic flows (TCM-TF) 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 TCM-TF. 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 12, 2014.
Suznjevic & Saldana Expires December 12, 2014 [Page 1]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
Copyright Notice
Copyright (c) 2014 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.
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 . . . . . . . . . . . . . . . . . 5
4. Multiplexing policies in TCM-TF . . . . . . . . . . . . . . . 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
Suznjevic & Saldana Expires December 12, 2014 [Page 2]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
degradation of the services when using TCM-TF, 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
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 TCM-TF 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 TCM-TF 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 TCM-TF sessions.
TCM optimizer
The host where TCM-TF optimization is deployed. If that hosts
corresponds to the ingress of the tunnel where native packets are
included it is called TCM-ingress optimizer (TCM-IO).
The host where TCM-TF multiplexed packets are received and rebuilt to
their native form is called TCM-egress optimizer (TCM-IO). It
corresponds to the tunnel egress.
policy manager
A network entity which makes the decisions about TCM-TF parameters:
multiplexing period; flows to be multiplexed together, depending on
their IP addresses, ports, etc. It is connected with a number of TCM
optimizers, and orchestrates the optimization that takes place
between them.
Suznjevic & Saldana Expires December 12, 2014 [Page 3]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
native packet
A packet sent by an application, belonging to a flow that can be
optimized by means of TCM-TF.
TCM-optimized 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 TCM-TF.
3. Considered services
The services considered suitable for being optimized by TCM-TF 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 TCM-TF.
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 TCM-TF:
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, TCM-TF optimization is neither interesting nor applicable.
Suznjevic & Saldana Expires December 12, 2014 [Page 4]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
3.2. Non real-time services
On the other hand, TCM-TF can be applied for some non real-time
services such as streaming audio, and instant messaging. These
applications are suitable for TCM-TF in terms of payload to header
size ratio, but different studies have shown that acceptable delays
for these services are up to several seconds [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 TCM-TF. 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 TCM-TF should not introduce
delays which would be noticeable in comparison with delays of such
magnitude (i.e., seconds and more).
4. Multiplexing policies in TCM-TF
A multiplexing policy defines the decision process for determining
which native packet goes in which multiplexed packet. The policies
proposed for TCM-TF 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 12, 2014 [Page 5]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
native traffic:
|<--P-->|<--P-->|<--P-->|<--P-->|<-t*->|<--P-->|
| | | | | | |
|# # | # # | | # #|######| # #|
-------------------------------------------------------> t
multiplexed traffic:
| | | | | | |
| |# |# | |# |## |#
| |# |# | |# |## |#
-------------------------------------------------------> t
* period reset (t<P) because size limit is reached
Combined "period" and "size limit" policies
Figure 1
It should be noted that the number of aggregated flows and their
packet rate will have an influence on the average multiplexing delay
added. If the number of flows is high, then the MTU size will be
reached before the end of the period in most cases, so the additional
delay will be smaller than the period. The recommendations presented
in this document present the maximum period values to be used as a
limit, in order to avoid delays which could impair the quality of the
service.
5. Detecting, classifying, and choosing network flows to be optimized
Three basic issues need to be solved in order to employ TCM-TF
optimization. First, the flows which are candidates for optimization
need to be detected from the overall traffic mix. Secondly, the
flows need to be classified into one of the defined categories so an
adequate multiplexing period can be assigned. Finally, the decision
whether a specific flow will be optimized or not using TCM-TF needs
to be made.
5.1. Optimization within an administrative domain
Several scenarios can be considered for the use of TCM-TF. If the
optimization is deployed within an administrative domain, then all
the data of the end hosts, the service class, etc., are known by the
TCM optimizers.
Two examples of this are 1) the end-to-end optimization and
aggregation of a number of flows between two offices of the same
Suznjevic & Saldana Expires December 12, 2014 [Page 6]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
company and 2) the agreement between a network operator and a game
provider in order to multiplex all the packets generated in an
aggregation network with destination on a game server. In these
cases, the detection and classification of the desired flows will be
straightforward, since the TCM optimizer can simply inspect the
destination IP address and port, and apply the traffic category
according to the kind of service.
5.2. Optimization based on statistics
If the optimization is not performed within an administrative domain,
then the detection and classification of the flows, and the decision
about multiplexing them, will have to be based on statistics of the
traffic and heuristics. The intelligence of the flow identification
method can be improved according to the statistics of already
classified flows. E.g., if a number of small-packet flows sharing
the same IP destination address are found, then this destination host
can be classified as a frequent receiver of small-packet flows, and a
tunnel including all the packets addressed to it can be set within a
common network path.
In addition, statistics can be enriched by the assignment of the
traffic class, taking into account that some services, in addition to
well-known ports, also have well-known IP addresses. E.g., the
traffic travelling to the IP address of a popular online game server,
can be associated with the proper traffic class; or the ports
corresponding to certain services can also be identified and used in
order to improve the classification.
The detection of the flows candidates for TCM-TF optimization should
be done based on flow characteristics, primarily on the packet
payload to header ratio and on the packet rate. As these properties
cannot be established from statistics of just one packet, it is
needed to gather a certain number of packets for each new flow
arriving at the TCM optimizer, and to use some heuristics in order to
decide whether to multiplex a certain flow or not.
The classification method employed for the TCM-TF needs to identify
only the flows which are candidates for the TCM-TF optimization.
Therefore, the classification problem is significantly simplified by
removal of peer to peer (P2P) downloading applications, video
streaming, data transfer, and all other services which in general,
utilize large packets. This is especially important as P2P
applications are known to use various non assigned ports which may
greatly ruin the performance of simple traffic classification
methods. For the purposes of TCM-TF optimization there is no need to
identify a particular application, only the delay sensitive class in
which that application falls. Also, the traffic classification
Suznjevic & Saldana Expires December 12, 2014 [Page 7]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
methods employed by TCM-TF need to be able to assign flows to
respective delay sensitive classes in real time. Current network
traffic classification methods can be grouped into [Nguyen_TCSurvey]:
o Port based - through lookup of port numbers of endpoints in the
Internet Assigned Numbers Authority (IANA)'s list of registered
ports.
o Payload based - through stateful reconstruction of session and
application information from each packet's content.
o Statistical - through comparison of the statistical properties of
the traffic at the network layer.
While payload inspection does give the best results, and is often
used as ground truth in classification of network traffic, it is
demanding computation wise. Also, these techniques may be
interpreted as a violation of privacy. For the purposes of TCM-TF we
recommend using a combination of port based classification (which can
yield very good results for games based on a client-server
architecture and remote desktop services), and inspection of
statistical properties of the flows. One such algorithm has been
employed for classification of different types of game flows and
showed good results [Han_GameClassification]. TCM-TF should use
metadata information regarding the traffic class of particular flow
where such information is available as that significantly simplifies
the detection and classification problem.
The decision whether the flow should be optimized with TCM-TF can be
made based on the following policies (configurations of the
multiplexing node):
o A static configuration - predefined rule set for each new
occurring flow, so the TCM optimizer makes a decision.
o A policy manager which dynamically enforces the rule set.
o The TCM optimizer demands instructions for each new flow from the
policy manager.
6. Delay recommendations
The three normally considered network impairments in the studies
related to subjective quality in real-time interactive games are:
o delay - can be reported as one-way-delay (OWD) [RFC2679] and two-
way-delay (Round Trip Time) [RFC2681]. In this document, under
the term latency, one way end-to-end delay is considered.
Suznjevic & Saldana Expires December 12, 2014 [Page 8]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
o delay variation - which is a statistical variance of the data
packet inter-arrival time, in other words the variation of the
delay as defined in RFC 3393 [RFC3393].
o packet loss - more important for certain applications, while other
include very good algorithms for concealing it (e.g., some game
genres).
In this document we give recommendations for overall tolerable delays
to be taken into account when optimizing network services by means of
TCM-TF. In an interactive service, the total delay is composed by
the addition of delays as defined in 3GPP TR 26.944 [TGPP_TR26.944].
o Transfer delay - from Host1 to Host2 at time T is defined by the
statement: Host1 sent the first bit of a unit data to Host2 at
wire-time T and that Host2 received the last bit of that packet at
wire-time T+dT. Thus, it includes the transmission delay (the
amount of time Host1 requires to push all of the packet's bits
into the wire) and the propagation delay in the network (the
amount of time it takes for the head of the packet to travel from
Host1 to Host2).
o Transaction delay - the sum of the time for a data packet to wait
in queue and receive the service during the server transaction.
+-----------+ +-----------+
| Host1 | | Host 2 |
+-----------+ +-----------+
S------- | ^ ^
| ------- | | |
| ------- |transf. |
| ------- | | |
| ------- | v |
| ------>R ^ |
| | | |
| |transac. total RTT
| | | |
| -------S v |
| ------- | ^ |
| ------- | | |
| ------- |transf. |
| ------- | | |
R<------ | v v
| |
S: Packet sent
R: Packet received
Figure 2
Suznjevic & Saldana Expires December 12, 2014 [Page 9]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
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 TCM-TF requires the addition of TCM optimizers 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 TCM-TF
is included in Figure 3:
+--------+
|client 1|___
+--------+ \
\ _ _
+--------+ +--------+ ( ` )_ +--------+ +------+
|client 2|--->| TCM-IO |--> ( ) `) --->| TCM-EO |-->|server|
+--------+ +--------+ (_ (_ . _) _) +--------+ +------+
/ Internet
/
+--------+ / <-----------tcm-tf----------->
|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 TCM
optimizer 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
TCM-TF 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 TCM-IO includes the time during
which the packets are retained until the bundled packet is sent, plus
processing time. In the TCM-EO however, the packets are not
retained, so only the processing time is considered.
Figure 4 shows the total delay, when a TCM optimizers 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 12, 2014 [Page 10]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
+---------+ +----------+ +---------+ +---------+
| Host 1 | | TCM-IO | | TCM-EO | | 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 12, 2014 [Page 11]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
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]. Tunneling
Multiplexed Compressed RTP (TCRTP) [RFC4170] already considers
tunneling, compressing and multiplexing VoIP packets.
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].
Suznjevic & Saldana Expires December 12, 2014 [Page 12]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
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
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 round trip time 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 with 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 TCM-TF. Under this category we include services for
M2M metering information, streaming audio, and instant messaging.
M2M metering services are suitable for TCM-TF 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]. The signalling
information related to M2M can also be optimized. Internet of Things
application layer protocols such as CoAP [CoAP], used in Constrained
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
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
Suznjevic & Saldana Expires December 12, 2014 [Page 13]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
degraded. Multiplexing periods of about 1 second can be considered
as sufficient for non real-time services (e.g., streaming audio).
+--------------------------+--------------------------+-------------+
| Service | Tolerable latency (OWD) | Mux. period |
+--------------------------+--------------------------+-------------+
| Voice communication | < 150ms | < 30ms |
| Omnipresent games | < 200ms | < 40ms |
| First person avatar | < 80ms | < 15ms |
| games | | |
| Third person avatar | < 120ms | < 25ms |
| games | | |
| Remote desktop | < 200ms | < 40ms |
| 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.
Suznjevic & Saldana Expires December 12, 2014 [Page 14]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
[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.
[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.
[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
Performance Metric Development", RFC 6390, October 2011.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012.
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.
Suznjevic & Saldana Expires December 12, 2014 [Page 15]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
[CoAP] Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", Internet-Draft Jun, 2013.
[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]
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.
[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 (TCM-TF)", Internet-Draft Jul, 2012.
Suznjevic & Saldana Expires December 12, 2014 [Page 16]
Internet-Draft Delay Limits and Policies for TCM-TF June 2014
[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.
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 12, 2014 [Page 17]