1 / 22

Paper Review: Latency Evaluation of Networking Mechanisms for Game Traffic

Paper Review: Latency Evaluation of Networking Mechanisms for Game Traffic. Jin, Da-Jhong. Motivation. Most interactive games need response time between 100 ~ 1000 ms depending on game genre. Challenging system requirement of interactive games: low latency for all users.

ina
Download Presentation

Paper Review: Latency Evaluation of Networking Mechanisms for Game Traffic

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Paper Review: Latency Evaluation of Networking Mechanisms for Game Traffic Jin, Da-Jhong

  2. Motivation • Most interactive games need response time between 100 ~ 1000 ms depending on game genre. • Challenging system requirement of interactive games: low latency for all users. • In this paper, they evaluate different techniques for delivering packets in timely manner.

  3. Game Trace Analysis: Game Stream Characteristics • Game trace analysis: • Small packet size • High interarrival time between packets.

  4. Experiment Setting • Because Small pkt size, high interarrival time between pkts, so they test under these condition: • Small pkt: 100 bytes • Pkt sent at low rate: interarrival time 50, 100, 200ms • RTT: 50, 100, 200ms • Loss rate: 0.1%, 0.5%, 2.5% • Emulator: netem • Test latency vs RTT under fixed IT and loss. • Test latency vs IT under fixed RTT and loss. • Test latency vs lost rate under fixed IT and RTT.

  5. Network Mechanisms • ENet (Developed for FPS Cube engine) • Modified ENet (Exponential backoff removed) • UDT (UDP-based Data Transfer Protocol) • TCP new reno (variation of TCP) • TCP bic (variation of TCP, binary increase congestion control) • Modified TCP (Exponential backoff removed) • TCP with RDB (variation of TCP, redundant data bundling) • SCTP • Modified SCTP (Enable bundling and fast retransmission)

  6. TCP new reno The main difference between each TCP variants is congestion control. Fast recovery: When 3 dupACKs are received, set ssthresh and cwnd are equal to ½ cwnd. When another dupACK is received, cwnd + 1 When a new pkt’s ACK is received, recover cwnd to the number in step 1. New reno fixed the error occurred when multiple packets loss in congestion window. When every pkt’s ACK in CW is received, recover.

  7. TCP BIC • TCP bic: binary increase congestion control, performs a fair share of the bandwidth faster than new reno. • Binary search: the value of cwnd try to climb to the middle point of wmax and wmin.

  8. Enhancement for Thin Stream • Modified TCP: exponential backoff removed to avoid the extreme latencies that occurs when consecutive packets are lost. • TCP with RDB: redundant data bundling, enable to bundle unacknowledged data if there is room in packet. Thus, loss packet may be recovered when next packet is received without retransmission.

  9. ENet Not a conjunction of TCP & UDP, but a single, uniform library layered over UDP. Partial reliability: retransmission are triggered using timeouts based on RTT. Modified ENet: exponential backoff removed.

  10. UDT Graph fromLaboratory for Advanced Computing / Univ. of Illinois at Chicago • UDT: UDP-based Data Transfer Protocol • UDT is a middleware designed to co-exist with TCP (differ from ENet)

  11. SCTP • SCTP • Fast retransmission and timeout mechanisms as in TCP • Default minRTO is 1000ms. • Modified SCTP: • exponential backoff removed • minRTO lowered to 200ms(standard TCP value)

  12. Other Protocol Setting • BIC, SCTP uses SACK. (New Reno has no option) • 001~100,101~200,401~500,501~600,801~900 received. • ACK: 201 • SACK: 401~600 & 801~900 • Turn off Nagle’s algorithm for TCP and SCTP. • Nagle’s alg: send data when receiving ACK or data is enough to fill MSS.

  13. Latency vs. RTT

  14. Latency vs. Interarrival Time

  15. Latency vs. Loss Rate

  16. Explanation • Average results are similar, except SCTP has higher latency. • Worst case results: • It is due to consecutive retransmissions of the same packet. • Two ways to improve: • Modified protocol is better than not modified one. Removing exponential backoff can improve latency. (Especially when loss rate is high) • TCP with RDB behave better because send multiple copies of a data element by bundling unacknowledged data in a packet.

  17. Bandwidth

  18. Price of Retransmission Latency • Traditional TCP needs less bandwidth. • UDT and TCP with RDB need higher bandwidth. • UDT always tried to use all the estimated bandwidth. When RTT is low, UDT will resend a packet multiple times to fill the pipe. • TCP with RDB bundles previous packets as long as there are unACK data. • Efficiently trade off bandwidth for lower latency by modification.

  19. Strength: • Widely measure existing protocols and middleware which can be used to run games. • Weakness: • There is only one packet size, 100 bytes.

  20. Thanks for Listening!

  21. When entering faster recovery: • if (low_window <= cwnd){ • prev_max = max_win; • max_win = cwnd; • cwnd = cwnd * (1-β); • min_win = cwnd; • if (prev_max > max_win) //Fast. Conv. • max_win = (max_win + min_win)/2; • target_win = (max_win + min_win)/2; • } else { • cwnd = cwnd *0.5; // normal TCP • }

  22. When not in fast recovery and an acknowledgment for a new • packet arrives: • if (low_window > cwnd){ • cwnd = cwnd + 1/cwnd; // normal TCP • return • } • if (is_BITCP_ss is false){// bin. increase • if (target_win – cwnd < Smax)// bin. • search • cwnd += (target_win-cwnd)/cwnd; • else • cwnd += Smax/cwnd; // additive incre. • if (max_win > cwnd){ • min_win = cwnd; • target_win =(max_win+min_win)/2; • } else { • is_BITCP_ss = true; • ss_cwnd = 1; • ss_target = cwnd+1; • max_win = default_max_win; • } • } else { // slow start • cwnd = cwnd + ss_cwnd/cwnd; • if(cwnd >= ss_target){ • ss_cwnd = 2*ss_cwnd; • ss_target = cwnd+ss_cwnd; • } • if(ss_cwnd >= Smax) • is_BITCP_ss = false; • }

More Related