SCTP over Satellite Networks

1
SCTP over Satellite Networks

• Mohammed AtiquzzamanSchool of Computer
  ScienceUniversity of Oklahoma.
• Email atiq_at_ieee.orgWeb www.cs.ou.edu/atiq
• Co-authors Shaojian Fu and William Ivancic

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

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

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

5
SCTP multi-streaming and multihoming
6
Illustration of SCTP multihoming
7
Illustration of Multi-streaming
8
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.

9
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
  

Total available chunk space 216 Bytes
Space used by other fields 44 Bytes
Space required for each Gap Ack Block 4 Bytes
Maximum number of Gap Ack Blocks (216
-44)/416380
10
TCP Selective Acknowledgment
4-bit Header Length field in TCP limits the
maximum space available for TCP options to 40bytes
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
----------------
Kind5 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)/84
11
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.

12
Large Window Support in SCTP
16-bit TCP window

Maximum TCP window size 65535214 bytes
Maximum SCTP window size 232-1 bytes
32-bit SCTP Advertised Receiver Window Credit
13
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.

Source
Destination
Data
ACK
Destination
Source
Data
ACK
14
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.

15
Delayed Acknowledgment Byte Counting (cont.)
cwnd5360 bytes
cwnd15000 bytes
S1536bytes
S11500 bytes
S2536bytes
S21500 bytes
Ack
SACK
SACK
cwnd6432 bytes (12 segments)
cwnd16500 bytes (11 segments)
SCTP delayed SACK(PMTU1500 bytes)
SCTP delayed SACK(PMTU1500 bytes)
Benefits of byte counting is lost
We recommend increasing the byte counting limit
to 2 PMTU by considering the delayed SACK.
16
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.

17
Recommended Use of SCTP over Satellite Networks
Common to TCP/SCTP
Unique to SCTP
18
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.

19

• Acknowledgements
• National Aeronautics and Space Administration
  (NASA) for supporting this research through grant
  no. NAG3-2528.
• Further Information
• Dr. Mohammed Atiquzzaman
• atiq_at_ou.edu, [phone]
• These slides are available at
• www.cs.ou.edu/atiq
  

Thank you