SCTP over Satellite Networks

1M. Atiquzzaman, SCTP over satellite networks

IEEE Computer Communications Workshop, Oct 20, 2003.

SCTP over Satellite Networks

Mohammed AtiquzzamanSchool of Computer Science

University of Oklahoma.Email: [email protected]

Web: www.cs.ou.edu/~atiq

Co-authors: Shaojian Fu and William Ivancic



Introduction

A number of enhancements to TCP have been proposed to enhance its performance over satellite networks.

No extensive study to investigate the suitability of SCTP, a new transport protocol being standardized by IETF, over satellite networks.

Main contributions of this study: Provide insights into the suitability of SCTP over satellite networks; Highlight the different features of SCTP which may help SCTP to

achieve the performance of “TCP with enhancements” in satellite environments;

Determine the effects of the unique features of SCTP in improving its performance over satellite links;

Provide recommendations on using SCTP over satellite networks.



Satellite Networking Characteristics

Long propagation delay: Propagation delay between an earth station and a GEO satellite is around

120-140ms. Requires sender long time to probe the network capacity and detect the

possible loss of segments. Expensive satellite bandwidth is wasted.

Large delay-bandwidth product: GEO satellite link is a typical case of the Long Fat Pipe (LFP), which

features a large delay bandwidth product.

Corruption loss during transmission: Large transmission distance of satellite links results in a low SNR and

consequently a high Bit Error Rate (BER). Cause TCP and SCTP senders to reduce their transmission rates

unnecessarily.



Stream Control Transmission Protocol

SCTP (RFC 2960) is being developed by IETF as the next generation transport protocol.

Reliable: retransmission of lost packets, ack of packets. In-order delivery: re-sequencing at the destination.

Transport layer protocol which operates on top of an unreliable connectionless network layer such as IP.

Transparent to IPv4 or IPv6

Key Unique features: Support for multiple logical streams to improve data transmission

throughput; Support for multiple network interfaces to achieve high availability; More secure mechanisms to prevent threats such as Denial of

Service (DoS) attack.



SCTP multi-streaming and multihoming



Illustration of SCTP multihoming



Illustration of Multi-streaming



SCTP and TCP: Common features

Congestion control mechanism Slow Start and Congestion Avoidance;

Transmission error Recovery Fast Retransmit; SCTP doesn't have an explicit Fast Recovery phase, but achieves

this automatically with the use of SACK.

Path MTU discovery SCTP has a slightly different support for path MTU discovery -

separate path MTU estimates must be maintained for each destination IP address.

Selective acknowledgement (SACK) Use of SACK is mandatory in SCTP, whereas it is optional in TCP.



SCTP Selective Acknowledgment

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 |Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #1 Start | Gap Ack Block #1 End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / ... / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #N Start | Gap Ack Block #N End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / ... / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Total available chunk space: 216 Bytes

Maximum number of Gap Ack Blocks: (216 -4×4)/4=16380

Space used by other fields: 4×4 Bytes

Space required for each Gap Ack Block: 4 Bytes



TCP Selective Acknowledgment

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Kind=5 | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Left Edge of 1st Block |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Right Edge of 1st Block |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

/ /

/ ... /

/ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Left Edge of nth Block |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Right Edge of nth Block |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Space required for one SACK block: 8 bytes

Maximum number of TCP SACK Blocks: Integer[(40-2)/8]=4

4-bit “Header Length” field in TCP limits the maximum space available for TCP options to 40bytes



Advantage of large number of SCTP SACK blocks

Satellite link features high BER and large TCP window.

There is larger possibility of multiple losses in a single window.

3 or 4 blocks in TCP may not be sufficient for reporting segment losses.

Larger number of SACK blocks make SCTP more robust in the case of multiple losses.



Large Window Support in SCTP

32-bit SCTP Advertised Receiver Window Credit

16-bit TCP window

16-bit TCP window 14 bits by window scaling

{Maximum TCP window size: 65535×214 bytes

Maximum SCTP window size: 232-1 bytes



SCTP Large window support

TCP supports windows up to 216 bytes; TCP requires window scaling option

(RFC 1323) to support large windows;

SCTP has a natural support for large windows up to 232 bytes to fill out the pipe.

ACK

Data

DestinationSource

ACK

DataSource Destination



Delayed Acknowledgment & Byte Counting

Byte counting: the cwnd is increased based on the number of bytes acknowledged by the SACK instead of by the number of ACKs as in TCP.

Byte counting decouples the cwnd increase from the arrival frequency of the SACKs, which is important in satellite environments by speeding up the slow start stage.

SCTP limits the cwnd increase to one PMTU per SACK. When the total number of bytes acknowledged by a single SACK exceeds PMTU, the benefit of byte counting is impaired.



Delayed Acknowledgment & Byte Counting (cont.)

cwnd=10 segmentsS1=536bytesS2=536bytes

cwnd=11 segments

TCP delayed Ack

cwnd=5360 bytesS1=536bytesS2=536bytes

cwnd=6432 bytes(12 segments)

SCTP delayed SACK(PMTU=1500 bytes)

cwnd=15000 bytesS1=1500 bytes

cwnd=16500 bytes(11 segments)

SCTP delayed SACK(PMTU=1500 bytes)

S2=1500 bytes

Ack SACKSACK

We recommend increasing the byte counting limit to 2 PMTU by considering the delayed SACK.

Benefits of byte counting is lost



SCTP support for ECN

Explicit Congestion Notification (ECN) helps determining the

exact reason (congestion vs. corruption losses) of segment losses, preventing the sender from unnecessarily entering congestion

control.

SCTP has explicit support for ECN: Endpoints can negotiate about ECN capabilities during association

setup; When the SCTP receiver detects the “CE” bit in the IP

header of a received segment, it will use an Explicit Congestion

Notification Echo (ECNE) to notify sender about the congestion; Sender will respond with Congestion Window

Reduce (CWR) indicating that the cwnd has been reduced.



Recommended Use of SCTP over Satellite Networks

Mechanism TCP Use

(RFC 2488)

SCTP Use Where

Path MTU Discovery Recommended Recommended S

Slow Start Required Required S

Congestion Avoidance Required Required S

Fast Retransmit Recommended Recommended S

Fast Recovery Recommended Implicitly Used S

SACK Recommended Implicitly Used S, R

Delayed SACK Recommended Recommended R

Large Receiver Window Recommended Implicitly Used S, R

SCTP Multi-Homing N/A Recommended S, R

SCTP Multi-Streaming N/A Recommended S, R

Byte Counting N/A Implicitly Used S, R

Larger Byte Counting Limit N/A Recommended S

Larger Initial cwnd N/A Recommended S

ECN N/A Recommended S, R

Com

mon to T

CP

/SC

TP

Unique to

SC

TP



Conclusion

New SCTP features make this new transport protocol suitable for long-delay, high BER satellite links.

Some issues for using SCTP over satellite links remains unresolved:

SCTP/IP Header Compression in high BER environment Bias against long-RTT associations during congestion avoidance SCTP over asymmetrical forward and backward satellite links

Some TCP enhancements, such as Protecting Against Wrapped Sequence (PAWS) numbers and Round Trip Time Measurement (RTTM) require timestamp option which is not available in SCTP. New chunk type needs to be defined.



Acknowledgements National Aeronautics and Space Administration (NASA) for

supporting this research through grant no. NAG3-2528.

Further Information

Dr. Mohammed Atiquzzaman

[email protected], (405) 325 8077

These slides are available at

www.cs.ou.edu/~atiq

SCTP over Satellite Networks

Documents

Transcript of SCTP over Satellite Networks