Re: [tcmtf] BoF feedback: Application-limited TCP

["Jose Saldana" <[e-mail]>]

I am currently deploying NS2 simulations for a paper I am preparing for IEEE
CCNC 2014. I have some preliminary results I will share here, just if they
can shed some light to this (interesting) debate.

I wasn't able to report these results during the BoF. No time for that in a
face-to-face meeting.

I am using an NS2 dumbbell scenario, with two branches. One of them has a
"sawteeth" delay and the other doesn't.

(to be seen with Courier letters)
#   node0 o-------o node8                 o node1    
#                  \                     /
#            node9  \ node4      node5  / 
#   node6 o-----o----o-----------------o-----o node7   
#                   /                   \
#           node2  o                     o node3
#
# a "number_of_connections_0_1_" of WoW are set from node0 (client) to node1
(server)
# a "number_of_connections_6_7_" of WoW are set from node6 (client) to node7
(server)
# an additional multiplexing delay is added from node8 to node4, and from
node9 to node4
# connection node2-node3 is for background traffic (not used so far)

A "sawteeth" delay is the delay you can expect if you add a "multiplexing
period" T: packets arriving at the beginning or the period are delayed T ms,
and packets arriving in the end are delayed 0 ms. The average delay is T/2.

(to be seen with Courier letters)
|     |     |     |     |     ^
|\    |\    |\    |\    |     |
| \   | \   | \   | \   |     T
|  \  |  \  |  \  |  \  |     |
|   \ |   \ |   \ |   \ |     |
|    \|    \|    \|    \|     v

       <-T->

What I am doing with NS2 is to make a "competition" between:
- A number "N" of TCP-based gaming flows  node0-node1, adding a "sawteeth"
delay with period T
- a number "M" of TCP-based gaming flows node6-node7, without that delay

This is something similar to the typical papers in which RTT unfairness is
measured for TCP.

Other simulation parameters: NS2 FullTCP is used for the game flows;
bandwidth of each client-server flow: 1.47 kbps (Questing activity of World
of Warcraft); bandwidth server-client: 18.13 kbps; OWD of the bottleneck: 20
ms; OWD of the rest of links: 10ms; simulation duration: 200 sec; server
population: 100 players on each of the servers.

Some results (no background traffic so far):

A) N=50; M=50; Bottleneck=10Mbps; T=50ms

BW node0->node1 = 74kbps (aggregate throughput obtained by all the flows)
BW node6->node7 = 75kbps

B) N=100; M=100; Bottleneck=300kbps; T=50ms

BW node0->node1 = 144kbps
BW node6->node7 = 147kbps

C) N=100; M=100; Bottleneck=250kbps; T=25ms

BW node0->node1 = 117kbps
BW node6->node7 = 131kbps

D) N=100; M=100; Bottleneck=250kbps; T=50ms

BW node0->node1 = 115kbps
BW node6->node7 = 133kbps


Some preliminary conclusions:
- No difference is observed when bandwidth is high enough (A).
- Small differences are observed if bandwidth is a bit higher than the sum
of the throughput of all the flows (B)
- The differences become more significant if bandwidth is scarce (C) and (D)

So multiplexing may reduce the obtained throughput in some cases, in a
similar way to RTT unfairness. I will also have to compare "sawteeth delay"
and a constant additional delay in subsequent tests.

Clearly, this is something that can be further studied, as you can guess. I
will write this research paper this month and let you know.

Thanks!

Jose

-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]] En nombre de Jose
Saldana
Enviado el: sábado, 03 de agosto de 2013 11:09
Para: [e-mail]
CC: 'Luigi Iannone'; 'Muthu Arul Mozhi Perumal (mperumal)'; Mirko Sužnjević
Asunto: Re: [tcmtf] BoF feedback: Application-limited TCP

This is something I tried to explain during the BOF, but perhaps I wasn't
able to set it clear: when we are talking about multiplexing TCP flows, we
are not thinking about normal TCP flows, but about very specific ones, in
which the information is generated during the TCP session itself.

These three papers [1], [2], [3] are about this question: A TCP-based online
game generates TCP packets as the player generates new commands. The PUSH
bit of the TCP header is set to 1 in order to make the TCP stack send it as
soon as possible, and ACKs are piggybacked onto the packets from the server
and vice versa.

But there are some TCP features that do not work properly for these flows,
since they are thought for "network-limited" TCP flows, whereas these games
generate "application-limited" TCP flows (as Mirko explained in the online
games tutorial on Thursday morning):

- Some TCP mechanisms directly deteriorate the experience of the players
(delayed ACK, Nagle algorithm)

- Some other TCP mechanisms do not work efficiently for MMORPGs (cwnd
reduced due to the application having nothing to send)

So which would be the effect of an additional multiplexing delay on a bunch
of "application-limited" TCP flows? I am currently doing NS2 simulations for
a paper I am preparing for IEEE CCNC 2014. I have some preliminary results I
will share here, just if they can shed some light to this (interesting)
debate. I am summarizing them in another e-mail.

Best regards,

Jose


[1]	C-C. Wu K-T. Chen, C-M. Chen, P. Huang, and C-L. Lei, "On the
Challenge and Design of Transport Protocols for MMORPGs," Multimedia Tools
and Applications (special issue on Massively Multiuser Online Gaming Systems
and Applications), Vol. 45, No. 1, pp. 7-32, 2009.
[2]	C. Griwodz and P. Halvorsen. "The fun of using TCP for an MMORPG,"
Proceedings of international workshop on Network and operating systems
support for digital audio and video (NOSSDAV '06). ACM, New York, NY, USA,
2006.
[3]	K-T. Chen, C-Y. Huang, P. Huang and C-L. Lei, "An Empirical
Evaluation of TCP Performance in Online Games", Proceedings of  the 2006 ACM
SIGCHI international conference on Advances in computer entertainment
technology ACE 06, Hollywood, California, USA, 2006.


_______________________________________________
tcmtf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcmtf