27/02/2019 Improving retransmission delays for thin streams Andreas Petlund Simula Research Laboratory and University of Oslo Andreas Petlund 2007

Agenda Background / Funcom traces SCTP and retransmission mechanisms 27/02/2019 Agenda Background / Funcom traces SCTP and retransmission mechanisms Tests and results Fairness considerations Ongoing and future work 2/27/20194/5/2001 Andreas Petlund 2007

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] 2/27/20194/5/2001

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

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. 2/27/20194/5/2001

Stream Control Transmission Protocol 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] sender receiver (re)transmission queue Network SACK 2/27/20194/5/2001

Retransmission by Time-Out 27/02/2019 Retransmission by Time-Out sender receiver 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 SACK SACK 2/27/20194/5/2001 Andreas Petlund 2007

Retransmission by Fast Retransmit sender receiver 4 SACKs needed for fast retransmit + thin streams = “all” retransmissions due to timeouts Network SACK no SACK no SACK no SACK no 2/27/20194/5/2001

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

Enhancement: Fast Retransmit Bundling sender receiver 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 SACK no SACK no SACK no SACK no 2/27/20194/5/2001

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 changes for 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 2/27/20194/5/2001

Lksctp performance Lksctp: RTT100, INT250 2/27/20194/5/2001

Lksctp performance Large reduction in maximum and average latency 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. 2/27/20194/5/2001

Performance comparison 27/02/2019 Max values 99 percentiles Average Om Exponential backoff: Ikke stor minskning paa gjennomsnitt, men stor reduksjon I max-verdier Min RTO og FR: Tar gjennomsnittet ned. Kombinasjon gir gode resultater paa begge 2/27/20194/5/2001 Andreas Petlund 2007

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. 2/27/20194/5/2001

TCP: Removal of Exponential Backoff Standard and modified timeout calculations 100 ms delay, average retransmission time Standard and modified timeout calculations 300 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 2/27/20194/5/2001

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). 2/27/20194/5/2001

Questions? ? 2/27/20194/5/2001