Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

The three normally considered network impairments in the studies related to subjective quality in real-time interactive games are: delay - can be reported as one-way-delay (OWD) and two-way-delay (Round Trip Time) . In this document, under the term latency, one way end-to-end day is considered. jitter - which is a statistical variance of the data packet inter-arrival time, in other words the variation of the delay. 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 of overal tollerable delays for previously listed real-time network services. In an interactive service, the total delay is composed by the addition of delays as defined in 3GPP TR 26.944 . 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 Transaction delay - the sum of the time for a data packet to wait in queue and receive the service during the server transaction. Figure 1 shows these delays. The labeled times (S and R) designate the times in which the packet is sent or received by the network card interface.

R ^ | | | | | | |transac. total RTT | | | | | -------S v | | ------- | ^ | | ------- | | | | ------- |transf. | | ------- | | | R<------ | v v | | S: Packet sent R: Packet received ]]> 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 Internet. The packets are demultiplexed and rebuilt before being forwarded to the application server. An scheme of TCMTF is included in Figure 2:

| mux |--> ( ) `) --->| demux |-->|server| +------+ +-----+ (_ (_ . _) _) +-------+ +------+ . / Internet . / +------+ / <-----------tcmtf-----------> |user n|_/ +------+ ]]> This technique groups packets in order to build a multiplexed one. So "multiplexing period" has to be defined in the multiplexer. When it ends, all the arrived packets are sent together in the same bundle. Therefore, multiplexing delay caused by tcmtf optimization techniques can be seen as an increase of transfer delay. The delay in the multiplexer is caused by the time the packets are retained until the bundled packet is sent, plus processing time. However, in the demultiplexer packets are not retained, so only processing time is considered. Figure 3 shows the total delay, when a multiplexer and a demultiplexer are added. It should be noticed that multiplexing can be deployed independently in the two directions, or only in one of them, as shown in Figure 3.

R ^ | | | | | | |transac. | | | | | | --------S v | | -------- | ^ | | -------- | | | | -------- | transf. | | ------- | | | R<------ | v v | | S: Packet sent R: Packet received ]]> If a policy defining a multiplexing period is used, then the average latency added to each packet will be half the multiplexing period. 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 propagation, processing and transmission delays is under the maximum tolerable delay, then multiplexing will be possible without harming user's experience. The calculation of the overal delay may be performed according to the ITU-T Y.1541 reccomendation The difference will give the maximum recommended multiplexing period. Next, we will report the maximum tolerable latencies for the previously listed real-time network services.

For conversational audio, the International Telecommunication Union recommends in less than 150 millisecond one-way end-to-end delay for high-quality real time traffic, but delays between 150ms and 400ms are acceptable. For a streaming audio, delay constraints are much looser, the delay should be less than 10s .

Online games are a large area comprising many game genres which have different latency requirements. This draft focuses on real-time online games and endorses the general game categorization proposed in 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 500ms. These games include include Role Playing Games (RPG) and Massively Multiplayer Online Role-Playing Games (MMORPG). First Person Avatar, in which threshold of acceptable latency is 100ms. The most popular subgenre of them are First Person Shooters, such as "Call of Duty" or "Halo" series. The study evaluated players' performance of certain tasks while increasing latency, and reported latencies in 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 was carried out in . As a result, they stated that latencies about 80ms could be considered as acceptable, since the games were 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 lesser on the decision to leave the game . A study oriented to evaluation of Mean Opinion Score (MOS), based on variation of delay and jitter for MMORPGs, suggested that MOS drops below 4 for delays greater than 120 ms . 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 latency is between 150ms and 200ms latencies. While original classification work states that latencies up to 1s are tolerated by omnipresent games, other studies argued that only latencies up to 200ms are tolerated by players of RTS games .

For the services of remote computer access, the delays are dependent on the task performed through the remote desktop, which are categorized into audio, video and data (reading, web browsing, document creation). A QoE study indicates that for audio latencies below 225 ms and for data latencies below 200 ms are tolerated . We group all the results in the Table 1 indicating the maximum allowed of latencies and proposed multiplexing periods. Proposed multiplexing periods are guidelines, since the exact values are dependant of existing the delay in the network. It should be noted that multiplexing periods of about 1 second can be considered as enough for non real time services (e.g., web browsing and streaming audio). Service Tolerable latency (OWD) Mux. period Voice communication < 400ms < 80ms Omnipresent games < 300ms < 60ms First person avatar games < 100ms < 20ms Third person avatar games < 200ms < 40ms Remote desktop < 200ms < 40ms