Considerations of SCTP Retransmission Delays for Thin Streams

1. LCN 2006: 31st IEEE Conference on Local Computer Networks, Tampa, FL, USA, November 2006 Considerations of SCTP Retransmission Delays for Thin Streams Jon Pedersen1, Carsten Griwodz1,2 & Pål Halvorsen1,2 1Department of Informatics, University of Oslo, Norway 2Simula Research Laboratory, Norway {jonped, griff, paalh}@ifi.uio.no

2. Overview • Latency problems for thin streams • SCTP as an alternative to TCP • Experiments • New experiments • Conclusions

3. Thins Streams • Transport protocols being developed for throughput-bound applications • BUT, there exist 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. 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 • … • suppose to address low latencies“require response between 500 – 1200 ms” … or “initiation of error procedures” [rfc 2719] (re)transmission queue Network

5. Test Set Up • Linux 2.6.15 with lksctp • 100 bytes packets • 4 packets per second  3.2 Kbps • Network emulated using netem • dropp • delays (RTTs: 0, 100, 200, 400 ms) SCTP

6. Results: lksctp for Thins Streams • Even worse than TCP!!! • Why these high delays? • Two ways of triggering retransmissions of a lost chunk…

7. SACK SACK 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

8. no no no no SACK SACK SACK SACK Retransmission by Fast Retransmit sender receiver 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 Enhancement: Removal of Exponential Backoff sender receiver retransmission of green packet due to timeout ENHANCEMENT: remove exponential backoff (re)transmission queue Network

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

11. Enhancements • Modified retransmission timer • removal of exponential backoff • minRTO = 200 ms (as in TCP) • Modified retransmission bundling • always allow aggressive bundling for fast retransmit • Modified fast retransmit • tested fast retransmit after 1 SACK • Thin stream detection • fewer packets in flight to trigger a fast retransmit • added tracking of outstanding packets • less than 4 in flight = thin stream

12. Enhancement: Results (200 ms) • Considerable reduction in average and maximum latencies • Increase in number of fast retransmissions compared to timeouts • Increase in number of retransmissions

13. New lksctp versions & New Test Set Up • New lksctp versions has been developed • 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 • New 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 • Many web-connections generating cross traffic (and thus losses) WEB WEB SCTP

14. Results: New lksctp • Still high average and worst case latencies

15. Results: Fast Retransmission Modification Fast retransmit modification – 1 SACK • Reduction in maximum and average latency • As expected a large increase in fast retransmit • An increase in spurious retransmissions

16. Results: Removed Exponential Backoff Removed exponential backoff • Reduction in maximum and average latency • An increase in spurious retransmissions • Retransmission aggressiveness does not really pose a congestion threat since the amount of data waiting to be sent is always less than the minimum transmission window

17. Results: Reduced Minimum Time-out Reduced minRTO • Faster timeouts • Reduction in maximum and average latency • An increase in spurious retransmissions

18. Results: All Modifications Combined All thin stream modifications • A further reduction in maximum and average latency • As expected an increase in fast retransmit • An increase in spurious retransmissions

19. Conclusions • Based on SCTP description we expected (hoped for) reduced latencies compared to TCP • Enhancements like • reduced minRTO • removal of exponential backoff • removal of delayed SACKs • … reduce latencies for thin streams • The enhancements increase the number of spurious retransmissions, but maybe not important for thin streams!!??