1 / 18

Improving Retransmission Delays for Thin Streams

This study explores the retransmission mechanisms for thin streams and proposes modifications to reduce retransmission delays. Tests and results are presented, along with ongoing and future work.

phillipi
Télécharger la présentation

Improving Retransmission Delays for Thin Streams

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. Improvingretransmission delays for thin streamsAndreas PetlundSimula Research Laboratory and University of Oslo

  2. Agenda Background / Funcom traces SCTP and retransmission mechanisms Tests and results Fairness considerations Ongoing and future work

  3. Thin Streams • Transport protocols being developed for throughput-bound applications • BUT, there exists several low-rate, time-dependent applications • Anarchy Online MMORPG Case Study • average delay: ~250 ms • max delay: 67 seconds (6 retransmissions) • packets per second: <4 (less then one per RTT) • average packet size: ~120 bytes • average bandwidth requirement: ~4 Kbps All TCP variations available in Linux (2.6.15) fail to properly support time-dependent “thin streams”  targeted for high rate streams only [nossdav 2006]

  4. TCP 1st retransmission Times of first retransmission, RTT=100 ms 1% loss 5% loss 0% jitter 10% jitter BIC FACK SACK Vegas DSACK New Reno Westwood+ DSACK&FACK

  5. Thin Streams - Continued • Identifying thin streams • Ability to make use of retransmission mechanisms. • Fast retransmit (3 or 4 Duplicate ACKs). • Retransmission timeouts. • Criteria for triggering modifications: • Packets In Flight: -for SCTP tests: PIF = 4 • Dependency of RTT: - has to be considered • Adapting to severe loss: PIF * 1 / (1 – p / 100) • Apply modifications only when criteria is fulfilled.

  6. SACK Stream Control Transmission Protocol sender receiver • SCTP should support signaling • acknowledged error-free transfers • data fragmentation according to MTU • packet boundary maintenance • sequenced delivery within multiple streams • bundling • partial reliability • … • supposed to address low latencies“require response between 500 – 1200 ms” … or “initiation of error procedures” [rfc 2719] (re)transmission queue Network

  7. SACK SACK sender receiver Retransmission by Time-Out • Timeout is dependent on • minRTO = 1000 ms • estimated RTT based on SACKs • BUT SACKs are delayed • one ACK for two packets or • 200 ms timer • influences estimated RTT, especially for thin streams • RTO value grows retransmission of packet with green chunks due to timeout (re)transmission queue Network

  8. no no no no SACK SACK SACK SACK sender receiver Retransmission by Fast Retransmit 4 SACKs needed for fast retransmit + thin streams = “all” retransmissions due to timeouts Network

  9. time in RTTS 8 6 4 2 retransmission number 1 2 3 4 sender receiver Enhancement: Removal of Exponential Backoff retransmission of orange packet due to timeout ENHANCEMENT: remove exponential backoff (re)transmission queue Network

  10. no no no no SACK SACK SACK SACK sender receiver Enhancement: Fast Retransmit Bundling ENHANCEMENT: piggyback all chunks in retransmission queue retransmission of orange packet (chunks) due to dupACKs grey packet is NOT piggybacked when dupACKs(but would be if due to timeout) retransmission queue Network

  11. lksctp versions & test set up • There have been some improvements in lksctp since we started this work. • lksctp in 2.6.16 (2.5.72-0.7.1) • only one retransmission due to fast retransmit, next timeout • only 3 SACKs required for fast retransmits • lksctp in 2.6.17 has no major changesfor our scenario. • Most recent tests • 100 B packets • RTTs:0, 50, 100, 150, 200, 250 ms • Packet inter-arrival times:50, 100, 150, 200, 250 ms • Dynamic thin stream detection • Tagging of chunks to indicate retr. type • Many web-connections generating cross traffic (and thus losses) WEB WEB SCTP

  12. Lksctp: RTT100, INT250 Lksctp performance

  13. Lksctp performance RTT100, INT250 2.6.16 lksctp All modifications • Large reduction in maximum and average latency • An increase in spurious retransmissions -Tolerable due to the low datarate.

  14. Performance comparison Max values 99 percentiles Average

  15. Fairness considerations and tests Modifications increases aggressiveness of stream - Exponential back-off. - Fast retransmit. - Minimum retransmission time out. We want to test whether fairness is in jeopardy.

  16. TCP: Removal of Exponential Backoff Standard and modified timeout calculations 300 ms delay, average retransmission time Standard and modified timeout calculations 100 ms delay, average retransmission time 1st retrans 2nd retrans 3rd retrans 1st retrans 2nd retrans 3rd retrans • Removal of the RTO backoff • Consistent reduction of delay for multiple losses • Reduced variation of smoothed RTO • But: effect is less pronounced when the RTT is big

  17. Ongoing and future work • Similar tests for TCP with modifications. • Test retransmission mechanisms in middleware (UDP/application layer) in comparison with modifications. • Incorporate modifications into existing flight simulator (SilentWings developed at Simula/Kalkulo). • Analyse Internet Exchange dumps to identify more applications with thin stream properties. • Thin streams TCP tests across the Atlantic. • Fairness-tests with many concurrent modified thin streams. • If TCP-tests are as promising as expected: • Lobbying for standard Linux kernel acceptance (as TCP option).

  18. Questions? ?

More Related