Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement

Coene, Lode

doi:10.17487/rfc4166

Cited by 6 publications

(4 citation statements)

References 2 publications

(2 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Furthermore, as the packets are relatively small, ways to put more data into one packet should be considered. Additionally, we consider the ideas that were mentioned in RFC4166 [5], reduction of the min-RTO and removal of exponential back-off. The RFC warns that these variations have negative side-effects by increasing the danger of spurious retransmissions and reduction of the congestion window.…”

Section: Enhancementsmentioning

confidence: 99%

See 1 more Smart Citation

Considerations of SCTP Retransmission Delays for Thin Streams

Pedersen

Griwodz

Halvorsen

2006

Proceedings. 2006 31st IEEE Conference on Local Computer Networks

View full text Add to dashboard Cite

show abstract

Section: Enhancementsmentioning

confidence: 99%

“…Grinnemo and Brunstrom [6] discuss the problem of minRTO, among other things, and propose a reduction to fulfill the requirements of RFC4166 [5], an RFC on the applicability of SCTP for telephony. The RFC itself discusses problems and solution approaches in its sections 3.2.1 and 3.3.…”

Section: Introductionmentioning

confidence: 99%

Considerations of SCTP Retransmission Delays for Thin Streams

Pedersen

Griwodz

Halvorsen

2006

Proceedings. 2006 31st IEEE Conference on Local Computer Networks

View full text Add to dashboard Cite

show abstract

“…Ladha et al [16] examined several methods of detecting spurious retransmissions and proposed modifications that would increase throughput but also increase the latency of individual lost packets. Grinnemo and Brunstrom [11] discuss the problem of RTO min , and propose a reduction to fulfil the requirements of RFC4166 [8], an RFC on the applicability of SCTP for telephony. The RFC itself discusses problems and solution approaches, and it proposes to choose the path within a multi-homed association that experiences the shortest delay, an approach that may be used as a supplement to other techniques for thin-stream scenarios.…”

Section: Related Workmentioning

confidence: 99%

“…One is to use fewer SACKs to trigger a fast retransmission because the number of SACKs is so small that they can rarely trigger a fast retransmission. We also consider the suggestions in RFC4166 [8], namely reduction of the RTO min and removal of exponential back-off. The RFC warns that these variations have negative side-effects by increasing the danger of spurious retransmissions and reducing the size of the congestion window.…”

Section: Enhancementsmentioning

confidence: 99%

Improving SCTP retransmission delays for time-dependent thin streams

Petlund

Beskow

Pedersen

et al. 2009

Multimed Tools Appl

View full text Add to dashboard Cite

A large number of network services rely on IP and reliable transport protocols. For applications that provide abundant data for transmission, loss is usually handled satisfactorily, even if the application is latency-sensitive (Wang et al. 2004). For data streams where small packets are sent intermittently, however, applications can occasionally experience extreme latencies (Griwodz and Halvorsen 2006). As it is not uncommon that such thin-stream applications are time-dependent, any unnecessarily induced delay can have severe consequences for the service provided. Massively Multiplayer Online Games (MMOGs) are a defining example of thin streams. Many MMOGs (like World of Warcraft and Age of Conan) use TCP for the benefits of reliability, in-order delivery and NAT/firewall traversal. It has been shown that TCP has several shortcomings with respect to the latency requirements of thin streams because of the way it handles retransmissions (Griwodz and Halvorsen 2006). As such, an alternative to TCP may be SCTP (Stewart et al. 2000), which was originally developed to meet the requirements of signaling transport. In this paper, we evaluate the Linux-kernel SCTP implementation in the context of thin streams. To address the identified latency challenges, we propose sender-side only enhancements that reduce the application-layer latency in a manner that is compatible with unmodified receivers. These enhancements can be switched on by applications and are used only when the system identifies the stream as thin. To evaluate the latency performance, we have performed several tests over various real networks and over an emulated network, varying parameters like RTT, packet loss and amount of competing cross traffic. When comparing our modifications with SCTP on Linux and FreeBSD and TCP New Reno, our results show great latency improvements and indicate the need for a separate handling of thin and thick streams.

show abstract