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

Considerations of Considerations of SCTP Retransmission Delays SCTP Retransmission Delays

for Thin Streamsfor 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

LCN 2006: 31st IEEE Conference on Local Computer Networks, Tampa, FL, USA, November 2006

2006 Jon Pedersen, Carsten Griwodz & Pål Halvorsen

LCN 2006, Tampa, FL, USA, November 2006

Overview

Latency problems for thin streams

SCTP as an alternative to TCP

Experiments

New experiments

Conclusions



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]



Stream Control Transmission Protocol

Network

sender receiver

(re)t

ransm

issi

on q

ueue

SA

CK

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]



Test Set Up Linux 2.6.15 with lksctp 100 bytes packets 4 packets per second 3.2 Kbps

SCTP

Network emulated using netem• dropp• delays (RTTs: 0, 100, 200, 400 ms)



Results: lksctp for Thins Streams

Even worse than TCP!!!

Why these high delays?

Two ways of triggering retransmissions of a lost chunk…



Retransmission by Time-Out

Network

sender receiver

(re)t

ransm

issi

on q

ueue

retransmission of packet with green chunks due to timeout

Timeout is dependent on

minRTO = 1000 ms

estimated RTT based on SACKs BUT SACKs are delayed

o one ACK for two packets oro 200 ms timer

influences estimated RTT, especially for thin streams

RTO value grows

SA

CK

SA

CK



Retransmission by Fast Retransmit

Network

sender receiver

SA

CK

no

SA

CK

no

SA

CK

no

SA

CK

no

4 SACKs needed for fast retransmit

+ thin streams

= “all” retransmissions due to timeouts



Enhancement: Removal of Exponential Backoff

Network

sender receiver

(re)t

ransm

issi

on q

ueue

retransmission of green packet due to timeout

ENHANCEMENT: remove exponential backoff

retransmission number

time in RTTS

2

4

6

8

1 2 3 4



Enhancement: Fast Retransmit Bundling

Network

sender receiver

retr

ansm

issi

on q

ueue

retransmission of green packet (chunks) due to dupACKs

blue packet is NOT piggybacked when dupACKs(but would be if due to timeout)

ENHANCEMENT: piggyback all chunks in retransmission queue

SA

CK

no

SA

CK

no

SA

CK

no

SA

CK

no



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



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

original SCTP

reduced minRTO & fast retransmit

modified timer restart

no SACK delay

Timeout 266 197 331 633

Fast retransmit 35 284 288 1

Total 301 481 619 634



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)

SCTP

WEBWEB



Results: New lksctp

Still high average and worst case latencies



Results: Fast Retransmission Modification

Reduction in maximum and average latency As expected a large increase in fast retransmit

An increase in spurious retransmissions

Fast retransmit modification – 1 SACK



Results: Removed Exponential Backoff

Reduction in maximum and average latency


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

Removed exponential backoff



Results: Reduced Minimum Time-out

Faster timeouts Reduction in maximum and average latency


Reduced minRTO



Results: All Modifications Combined

A further reduction in maximum and average latency As expected an increase in fast retransmit


All thin stream modifications



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!!??

Documents

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