1 / 19

Considerations of SCTP Retransmission Delays for Thin Streams

LCN 2006: 31st IEEE Conference on Local Computer Networks, Tampa, FL, USA, November 2006. Considerations of SCTP Retransmission Delays for Thin Streams. Jon Pedersen 1 , Carsten Griwodz 1,2 & Pål Halvorsen 1,2 1 Department of Informatics, University of Oslo, Norway

virginiaalexander
Download Presentation

Considerations of SCTP 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. 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!!??

More Related