+-----------+                          +-----------+
|   Host1   |                          |   Host 2  | 
+-----------+                          +-----------+
       S-------                                   |   ^       ^
       |       -------                            |   |       |
       |              -------                     |transfer   |
       |                     -------              |   |       |
       |                            -------       |   v       |
       |                                   ------>R   ^       |
       |                                          |   |       |
       |                                          |transac. total RTT
       |                                          |   |       |
       |                                   -------S   v       |
       |                            -------       |   ^       |
       |                     -------              |   |       |
       |              -------                     |transfer   |
       |       -------                            |   |       |
       R<------                                   |   v       v
       |                                          |
                    S: Packet sent
                    R: Packet received           

Figure 1

Figure 1 illustrates these delays. The labeled times (S and R) designate the times in which the packet is sent and received, respectively, by the network interface.

4. Delay recommendations

4.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 still 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, so the delay should be less than 10 s [ITU-T_G.1010].

4.2. Online games

Online games comprise game genres which have different latency requirements. This document focuses on real-time online games and endorses the general game categorization proposed in [Claypool_Latency] in which online games have been divided into:

• 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.
• 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).
• 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.

As remarked in [Bernier_Latency] and [Oliveira_online], different methods can be employed to combat delay in online games. The so-called “client-side prediction” has been largely used in First Person Shooters. It can be divided into “input prediction” and “dead reckoning,” where input prediction hides the latency for the client-controlled actions while dead reckoning hides the latency of other participating players.

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.

Other approach some studies have taken is to perform “objective measurements” [Kaiser_objective] a number of identical “bots”, i.e. virtual avatars controlled by Artificial Intelligence, are placed in the same virtual scenario and a number of parties between them are performed. If the number of parties if high enough, then the score will be the same for all the bots. Then, different network impairments (latency, jitter, packet loss) are added to one of the bots, and another set of tests is performed. The performance degradation of the network-impaired bot can then be statistically characterized.

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 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].

4.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].

4.4. Non real-time service

Under this category we include services for M2M metering information, streaming audio, and instant messaging. M2M metering services present a one way 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 [RFC7252], used in Constrained RESTful Environments (CoRE)[RFC6690]. 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].

4.5. Summary

We group all the results in 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., streaming audio).