Forward Error correction (FEC)
for SCTP in Satellite environment
Final Report
Submitted by: Yoav Caspi
Gilad Kent
Instructors: Itai Dabran - LCCN,
Shai Revzen - HDS
Summer Semester 2001 Project at the Laboratory of Computer Communication and Networking.
Computer Science Faculty. Technion.
This project was done in cooperation with Harmonic Data Systems.
1. Intoduction
1.1. Motivation
The current TCP stacks implement several algorithms to recover from a single loss, and to avoid network congestion. The performance of TCP can suffer dramatically when more than one segment is lost in one window. During the recovery algorithm, the TCP stack calculates some of its decisions according to the RTT (Round Trip Time) parameter. Both of these issues become together the main problem of TCP connection to satellites. When data is lost, most of the times it is more than one segment - the segments are lost in bursts, because of atmospheric changes and weather conditions for example.
Recovery of lost packets using retransmission requires an RTT (typically calculated RTT is 250ms, for 36000 Km Distance Satellite), which is expensive in terms of buffering capacity, and induces significant jitter in high-latency nets.
In order to overcome the poor performance of TCP in a satellite environment, we will use the SCTP transport protocol in this project instead. So as to lower the jitter in such environments, we will add to the SCTP protocol a forward error correction (FEC) algorithm.
1.1. SCTP overview
1.1.1. General
SCTP is a reliable transport protocol operating on top of a potentially unreliable connectionless packet service such as IP.
It offers the following services to its users:
· acknowledged error-free non-duplicated transfer of user data.
· data fragmentation to conform to discovered path MTU size.
· sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages.
· optional bundling of multiple user messages into a single SCTP packet.
· network-level fault tolerance through supporting of multi-homing at either or both ends of an association.
An SCTP association generally looks like this, so the services of SCTP are naturally at the same layer as TCP or UDP services:
Figure 1 – An SCTP Association
1.1.2. SCTP Data Units
The protocol data units (PDU) of SCTP are called SCTP packets. If SCTP runs
over IP (as described in [1]), an SCTP packet forms the payload of an IP
packet. An SCTP packet is composed of a common header and chunks. Multiple
chunks may be multiplexed into one packet up to the Path-MTU size. A chunk may
contain either control information or user data.
1.1.3. SCTP reliable transfer and congestion control mechanism
Flow control and congestion control in SCTP have been designed in a way which assures that SCTP traffic behaves in the network in the same way as TCP traffic does. This enables a seamless introduction of SCTP services into existing IP networks.
SCTP operates on two levels:
· Within an association the reliable transfer of datagrams is assured by using a checksum, a sequence number and a selective retransmission mechanism. Without taking the initial sequence into account, every correctly received data chunk is delivered to a second, independent level.
· The second level realizes a flexible delivery mechanism which is based on the notion of several independent streams of datagrams within an association.
Detection of loss and duplication of data
chunks is enabled by numbering all data chunks in the sender with the so-called
Transport Sequence Number (TSN). The acknowledgements sent from the receiver to
the sender are based on these sequence numbers.
Retransmissions are timer-controlled. The timer duration is derived from
continuous measurements of the round trip delay. Whenever such a retransmission
timer expires, (and congestion control allows transmissions) all
non-acknowledged data chunks are retransmitted and the timer is started again
doubling its initial duration (like in TCP).
When the receiver detects one or more gaps in the sequence of data chunks, each received SCTP packet is acknowledged by sending a Selective Acknowledgement (SACK) which reports all gaps. The SACK is contained in a specific control chunk. Whenever the sender receives four consecutive SACKs on the same data chunk this data chunk is immediately retransmitted (fast retransmit).
1.1.4. The Common Header
The
common header consists of 12 bytes. For the identification of an association,
SCTP uses the same port concept as TCP and UDP. For the detection of
transmission errors, each SCTP packet is protected by a 32 bit checksum
(Adler-32 algorithm), which is more robust than the 16 bit checksum of TCP and
UDP. SCTP packets with an invalid checksum are silently discarded. The common
header also contains a 32 bit value called verification tag. The verification
tag is association specific, and exchanged between the endpoints at association
startup. So there are two tag values used in one association. See section SCTP states
for detailed information on tags.
1.1.5. Chunks
Each
chunk begins with a chunk type field (ID value), which is used to distinguish
data chunks and different types of control chunks, followed by chunk specific
flags and a chunk length field needed because chunks have a variable length.
The value field contains the actual payload of the chunk.
So
far there are 13 chunk types defined for standard use. They are listed here below.
A full definition of the Payload Data have been copied here from RFC2960 since this is the
chunk we are interested in this project :
ID Value Chunk Type 0 - Payload Data (DATA) 1 - Initiation (INIT) 2 - Initiation Acknowledgement (INIT ACK) 3 - Selective Acknowledgement (SACK) 4 - Heartbeat Request (HEARTBEAT) 5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 6 - Abort (ABORT) 7 - Shutdown (SHUTDOWN) 8 - Shutdown Acknowledgement (SHUTDOWN ACK) 9 - Operation Error (ERROR) 10 - State Cookie (COOKIE ECHO) 11 - Cookie Acknowledgement (COOKIE ACK) 12 - Reserved for Explicit Congestion Notification Echo (ECNE) 13 - Reserved for Congestion Window Reduced (CWR) 14 - Shutdown Complete (SHUTDOWN COMPLETE) 15 to 62 - Reserved by IETF 63 - IETF-defined Chunk Extensions 64 to 126 - reserved by IETF 127 - IETF-defined Chunk Extensions 128 to 190 - reserved by IETF 191 - IETF-defined Chunk Extensions
192 to
254 - reserved by IETF
255
- IETF-defined Chunk Extensions
1.1.6. Payload Data chunk
The following format MUST be used for the
DATA chunk:
0 1 2 30 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 = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ // User Data (seq n of Stream S) /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1.1.7. Functional View of SCTP
The SCTP transport service can be
decomposed into a number of functions. These are explained in the remainder of
this section.
Association Startup and Takedown
An association is initiated by a request
from the SCTP user. A cookie mechanism
is employed during the initialization to
provide protection against security attacks.
The cookie mechanism uses a four-way
handshake, the last two legs of which are allowed to carry user data for fast
setup.
Sequenced Delivery within Streams
The term "stream" is used in SCTP
to refer to a sequence of user messages that are to be delivered to the
upper-layer protocol in order with respect to other messages within the same
stream. This is in contrast to its usage in TCP, where it refers to a sequence
of bytes.
SCTP assigns a stream sequence number to
each message passed to it by the SCTP user. On the receiving side, SCTP ensures
that messages are delivered to the SCTP user in sequence within a given stream.
However, while one stream may be blocked waiting for the next in-sequence user
message, delivery from other streams may proceed.
User Data Fragmentation
When needed, SCTP fragments user messages
to ensure that the SCTP packet passed to the lower layer conforms to the path
MTU. On receipt, fragments are reassembled into complete messages before being
passed to the SCTP user.
Acknowledgement and Congestion Avoidance
SCTP assigns a Transmission Sequence Number
(TSN) to each user data chunk.. The TSN is independent of any stream sequence
number assigned at the stream level. The receiving end acknowledges all TSNs
received, even if there are gaps in the sequence. In this way, reliable
delivery is kept functionally separate from sequenced stream delivery.
Chunk Bundling
SCTP packet as delivered to the lower layer
consists of a common header followed by one or more chunks. Each chunk may
contain either user data or SCTP control information. The SCTP user has the
option to request bundling of more than one user messages into a single SCTP
packet. The chunk bundling function of SCTP is responsible for assembly of the
complete SCTP packet and its disassembly at the receiving end.
Packet Validation
A mandatory Verification Tag field and a 32
bit checksum are included in the SCTP common header. The Verification Tag value
is chosen by each end of the association during association startup. Packets
received without the expected Verification Tag value are discarded.
The Adler-32 checksum should be set by the
sender of each SCTP packet to provide additional protection against data
corruption in the network. The receiver of an SCTP packet with an invalid
Adler-32 checksum silently discards the packet.
Path Management
The sending SCTP user is able to manipulate
the set of transport addresses used as destinations for Spackets. The SCTP path
management function chooses the destination transport address for each outgoing
SCTP packet based on the SCTP user's instructions and the currently perceived
reachability status of the eligible destination set. The path management
function monitors reachabilithrough heartbeats when other packet traffic is
inadequate to provide this SCTP user when reachability of any far-end transport
address changes. The path management function is also responsible for reporting
the eligible set of local transport addresses to the far end during association
startup, and for reporting the transport addresses returned from the far end to
the SCTP user.
1.1.8. SCTP Terminology – Key Terms
These terms are taken straight from the RFC2960 .
Active destination transport address
A transport address on a peer endpoint
which a transmitting endpoint considers available for receiving user messages.
Bundling
An optional multiplexing operation, whereby
more than one user message may be carried in the same SCTP packet. Each user
message occupies its own DATA chunk.
Chunk
A unit of information within an SCTP
packet, consisting of a chunk header and chunk-specific content.
Congestion Window (cwnd)
An SCTP variable that limits the data, in
number of bytes, a sender can send to a particular destination transport
address before receiving an acknowledgement.
Cumulative TSN Ack Point
The TSN of the last DATA chunk acknowledged
via the Cumulative TSN Ack field of a SACK.
Idle destination address
An address that has not had user messages
sent to it within some length of time, normally the HEARTBEAT interval or
greater.
Inactive destination transport address
An address which is considered inactive due
to errors and unavailable to transport user messages.
Ordered Message
A user message that is delivered in order
with respect to all previous user messages sent within the stream the message
was sent on.
Outstanding TSN (at an SCTP endpoint)
A TSN (and the associated DATA chunk) that
has been sent by the endpoint but for which it has not yet received an
acknowledgement.
Path
The route taken by the SCTP packets sent by
one SCTP endpoint to a specific destination transport address of its peer SCTP
endpoint. Sending to different destination transport addresses does not
necessarily guarantee getting separate paths.
Primary Path
The primary path is the destination and
source address that will be put into a packet outbound to the peer endpoint by
default. The definition includes the source address since an implementation MAY
wish to specify both destination and source address to better control the return
path taken by reply chunks and on which interface the packet is transmitted
when the data sender is multi-homed.
Receiver Window (rwnd)
An SCTP variable a data sender uses to
store the most recently calculated receiver window of its peer, in number of bytes.
This gives the sender an indication of the space available in the receiver's
inbound buffer.
SCTP association
A protocol relationship between SCTP
endpoints, composed of the two SCTP endpoints and protocol state information
including Verification Tags and the currently active set of Transmission
Sequence Numbers (TSNs), etc. An association can be uniquely identified by the
transport addresses used by the endpoints in the association. Two SCTP
endpoints MUST NOT have more than one SCTP association between them at any
given time.
SCTP endpoint
The logical sender/receiver of SCTP
packets. On a multi-homed host, an SCTP endpoint is represented to its peers as
a combination of a set of eligible destination transport addresses to which
SCTP packets can be sent and a set of eligible source transport addresses from
which SCTP packets can be received. All transport addresses used by an SCTP
endpoint must use the same port number, but can use multiple IP addresses. A
transport address used by an SCTP endpoint must not be used by another SCTP
endpoint. In other words, a transport address is unique to an SCTP endpoint.
SCTP packet
The unit of data delivery across the
interface between SCTP and the connectionless packet network (e.g., IP). An
SCTP packet includes the common SCTP header, possible SCTP control chunks, and
user data encapsulated within SCTP DATA chunks.
SCTP user application
The logical higher-layer application entity
which uses the services of SCTP, also called the Upper-layer Protocol (ULP).
Slow Start Threshold (ssthresh)
An SCTP variable. This is the threshold
which the endpoint will use to determine whether to perform slow start or
congestion avoidance on a particular destination transport address. Ssthresh is
in number of bytes.
Stream
A uni-directional logical channel
established from one to another associated SCTP endpoint, within which all user
messages are delivered in sequence except for those submitted to the unordered
delivery service.
Stream Sequence Number
A 16-bit sequence number used internally by
SCTP to assure sequenced delivery of the user messages within a given stream.
One stream sequence number is attached to each user message.
Transmission Sequence Number (TSN)
A 32-bit sequence number used internally by SCTP. One TSN
is attached to each chunk containing user data to permit the receiving SCTP
endpoint to acknowledge its receipt and detect duplicate deliveries.
Transport address
A Transport Address is traditionally defined by Network
Layer address, Transport Layer protocol and Transport Layer port number. In the
case of SCTP running over IP, a transport address is defined by the combination
of an IP address and an SCTP port number (where SCTP is the Transport protocol).
Unacknowledged TSN (at
an SCTP endpoint)
A TSN (and the associated DATA chunk) which has been
received by the endpoint but for which an acknowledgement has not yet been sent.
Or in the opposite case, for a packet that has been sent but no acknowledgement
has been received.
Unordered Message
Unordered messages are "unordered" with respect to any
other message, this includes both other unordered messages as well as other
ordered messages. Unordered message might be delivered prior to or later than
ordered messages sent on the same stream.
Verification Tag
A 32 bit unsigned integer that is randomly generated. The
Verification Tag provides a key that allows a receiver to verify that the SCTP
packet belongs to the current association and is not an old or stale packet from
a previous association.
1.1.9. Fault Detection capabilities in the SCTP:
Transmission Sequence Number (TSN)
- A 32-bit sequence number used internally by SCTP. One TSN is attached to
each chunk containing user data to permit the receiving SCTP endpoint to
acknowledge its receipt and detect duplicate deliveries as well as missing
chunks. SCTP supports out of order
Verification Tag - A 32 bit
unsigned integer that is randomly generated. The Verification Tag provides a key
that allows a receiver to verify that the SCTP packet belongs to the current
association and is not an old or stale packet from a previous association.
Checksum - For the detection of transmission errors , each SCTP packet is protected by a 32 bit checksum (Adler-32 algorithm). In the current implementation SCTP packets with an invalid checksum are silently discarded by receiving station.
The error detection capabilities we listed above assure us that errors will be detected. The drawback of SCTP (as well as TCP for that matter) in the current implementation is that the Recovery of errors detected is commonly to discard and retransmit. Recovery of lost packets using retransmission requires an RTT which is expensive in terms of buffering capacity, and induces significant jitter in high-latency nets. Forward error correction (FEC) is an idea that pays some BW, but lower the jitter considerably
1.2. Forward Error Correction overview
Forward error correction (FEC) is the means by which repair
data is added to a media stream, such that packet loss can be repaired by the
receiver of that stream with no further reference to the sender.
The basic FEC algorithm is as follows:
We will denote the number of source packets as k, the packet size as S,
the number of redundant packets m, and the number of
encoded packets as n. Such a code is called an (n,k) code and allows the
receiver to recover from m (=n-k) losses in a group of n encoded packets. This code illustrated in figure
3.
Figure 2 – Graphical representation of error correction
2. Project Goals
2.1. Finding an SCTP implementation and verify its functionality
Some STCP implementation exist nowadays , all of them still in developing stage. Our first goal will be choosing one of these implementations that runs under Linux (in the user mode) , and verify that its behavior is compatible with [1].
Another crucial criteria for choosing implementation is the clarity and documentation level of the code.
2.1. Adding FEC algorithm to the SCTP implementation
This is the main goal of the project, and it contains three stages:
· Choosing the FEC algorithm to be implemented
· Getting an overview of the SCTP features and the protocol behavior
· Embedding the chosen algorithm into the protocol source code
3. The chosen solutions
3.1. The chosen FEC Algorithm
The FEC algorithm we will apply is the most trivial one; simply adding a parity packet at the end of every 'strip' of SCTP packets (m=1 in the notation of paragraph 1.3). This algorithm will provide the ability to reconstruct one lost packet in every strip.
The parity packet will be encoded and decoded as a per byte bitwise-xor on all the packets of the strip, on all the packet's bytes excluding the SCTP common header.
Figure 3 -
FEC interleaving diagram with 'Strip Length' = 3
In order to increase the number of recovered packets in case of a burst of lost packets (which is the more likely situation), future enhancement for the mechanism can be use of FEC interleaving, that is adding an additional following parity packets which will include the previous parity packet as well as all its strip except for its first packet.
3.2.
The
chosen SCTP implementation
Some STCP implementation exist nowadays , all of them still
in developing stage. Our first goal was choosing one of these implementations
that runs under Linux (in the user mode) , and verify that its behavior is
compatible with the RFC.
Currently, there are 3 major SCTP implementations for Linux:
· University of Chicago – kernel
implementation
We didn't manage even to compile
this implementation. It seems that few files were missing in the last version
patch.
This version looks like it is in the first stage
of the developing process – not is a status for adding features like FEC.
In addition, kernel
implementation could have made our FEC adding process much harder than using a
user mode implementation (the overhead of compiling and restarting after every
code change is significant).
· University of Chicago – user
mode implementation
We managed to operate this
implementation, but we have found two major drawbacks in it:
o The implementation documentation was unfulfilling – we
couldn't understand easily the protocol modules and structure.
o The upper layer application wasn't in a stage that we
could have use it for testing our code addition.
· www.sctp.de implementation – user mode (the chosen one)
We chose to use the implementation from www.sctp.de - sctplib-1.0.0-pre13.
This SCTP implementation supports the current version of the protocol. It runs under Linux, FreeBSD and Mac OS X and supports IPv4 and IPv6.
The software is a result of a cooperation between Siemens and the Computer networking technology group of the University of Essen. It is published under the GNU public license.
The implementation includes a few application layer programs, and we used them to test its operation. It seems to work just the way we expected it. A sample operation results, in the protocol layer, can be found in section 3.4.
In addition to its proper functionality, the implementation is very well documented. Moreover, the implementation's discussion group seemed to be very "live" and supporting, and it helped us twice during the developing period, when we got "stucked".
3.3. Main application layer programs
· Terminal – can be used for
sending ascii data from one peer, and see it in the other peer (using discard
server).
Resemble to TCP’s netcat.
· Echo_tool – can be used for sending fluent data from one peer to another.
3.4. Example of using Terminal
This section contains a capture of a simple SCTP connection that was established using the terminal application. The capture was done by the Ethereal packet sniffer and it contains the initialization packets, followed by transferring of user data and ended with the heartbeat and heartbeat_ack packets.
The connection summery:
No. Time
Source
Destination
Protocol Info
92 6.790000
132.68.37.67
132.68.37.63
SCTP INIT
97 6.790000
132.68.37.63
132.68.37.67
SCTP INIT_ACK
98 6.790000
132.68.37.67
132.68.37.63
SCTP COOKIE_ECHO
99 6.790000
132.68.37.63
132.68.37.67
SCTP COOKIE_ACK
334 34.410000
132.68.37.67
132.68.37.63
SCTP DATA
335 34.410000
132.68.37.63
132.68.37.67
SCTP SACK
438 39.810000
132.68.37.63
132.68.37.67
SCTP HEARTBEAT
439 39.810000
132.68.37.67 132.68.37.63
SCTP HEARTBEAT_ACK
The detailed
packets:
Frame 92 (74 on wire, 74 captured)
Ethernet II
Internet Protocol, Src Addr: 132.68.37.67 (132.68.37.67),
Dst Addr: 132.68.37.63 (132.68.37.63)
Stream Control Transmission Protocol
Source port: 5000
Destination port: 5000
Verification tag: 0x00000000
Adler-32 checksum: 0x8d7c06d5
(correct)
INIT chunk requesting for 10
outbound streams and accepting up to 10 inbound streams
Identifier: 1 (INIT)
Flags:
0
Length:
28
Initiate
tag: 0x55eec553
Advertised reciever window credit (a_rwnd): 256000
Number of
outbound streams: 10
Number of
inbound streams: 10
Initial
TSN: 133922448
Supported
address types parameter reporting 1 address type
Frame 97 (166 on wire, 166 captured)
Ethernet II
Internet Protocol, Src Addr: 132.68.37.63 (132.68.37.63),
Dst Addr: 132.68.37.67 (132.68.37.67)
Stream Control Transmission Protocol
Source port: 5000
Destination port: 5000
Verification tag: 0x55eec553
Adler-32 checksum: 0x8e731fbd
(correct)
INIT_ACK chunk requesting for 10
outbound streams and accepting up to 10 inbound streams
Identifier: 2 (INIT_ACK)
Flags:
0
Length:
120
Initiate
tag: 0x3a3c1af3
Advertised reciever window credit (a_rwnd): 256000
Number of
outbound streams: 10
Number of
inbound streams: 10
Initial
TSN: 109468002
State
Cookie Parameter with 96 bytes cookie
Frame 98 (146 on wire, 146 captured)
Ethernet II
Internet Protocol, Src Addr: 132.68.37.67 (132.68.37.67),
Dst Addr: 132.68.37.63 (132.68.37.63)
Stream Control Transmission Protocol
Source port: 5000
Destination port: 5000
Verification tag: 0x3a3c1af3
Adler-32 checksum: 0x198e1aa5
(correct)
COOKIE ECHO chunk containing a
cookie of 96 bytes
Identifier: 10 (COOKIE_ECHO)
Flags:
0
Length:
100
Cookie
(96 bytes)
Frame 99 (50 on wire, 50 captured)
Ethernet II
Internet Protocol, Src Addr: 132.68.37.63 (132.68.37.63),
Dst Addr: 132.68.37.67 (132.68.37.67)
Stream Control Transmission Protocol
Source port: 5000
Destination port: 5000
Verification tag: 0x55eec553
Adler-32 checksum: 0x2a2d03a1
(correct)
COOKIE ACK chunk
Identifier: 11 (COOKIE_ACK)
Flags:
0
Length:
4
Frame 334 (90 on wire, 90 captured)
Ethernet II
Internet Protocol, Src Addr: 132.68.37.67 (132.68.37.67),
Dst Addr: 132.68.37.63 (132.68.37.63)
Stream Control Transmission Protocol
Source port: 5000
Destination port: 5000
Verification tag: 0x3a3c1af3
Adler-32 checksum: 0x57bf0ce1
(correct)
DATA chunk with TSN 133922448
(0:0) containing 27 bytes of payload
Identifier: 0 (DATA)
Flags:
3
Length:
43
TSN:
133922448
Stream
Identifier: 0x0000
Stream
sequence number: 0
Payload
protocol identifier: 0 (not specified)
Payload
(27 bytes)
Padding:
1 byte
Frame 335 (62 on wire, 62 captured)
Ethernet II
Internet Protocol, Src Addr: 132.68.37.63 (132.68.37.63),
Dst Addr: 132.68.37.67 (132.68.37.67)
Stream Control Transmission Protocol
Source port: 5000
Destination port: 5000
Verification tag: 0x55eec553
Adler-32 checksum: 0x707306a0
(correct)
SACK chunk acknowledging TSN
133922448 and reporting 0 gaps and 0 duplicate TSNs
Identifier: 3 (SACK)
Flags:
0
Length:
16
Cumulative TSN ACK: 133922448
Advertised receiver window credit (a_rwnd): 256000
Number of
gap acknowldgement blocks : 0
Number of
duplicated TSNs: 0
Frame 438 (62 on wire, 62 captured)
Ethernet II
Internet Protocol, Src Addr: 132.68.37.63 (132.68.37.63),
Dst Addr: 132.68.37.67 (132.68.37.67)
Stream Control Transmission Protocol
Source port: 5000
Destination port: 5000
Verification tag: 0x55eec553
Adler-32 checksum: 0x5d7a04ea
(correct)
HEARTBEAT chunk
Identifier: 4 (HEARTBEAT)
Flags:
0
Length:
16
Heartbeat
info parameter with 8 bytes of info
Frame 439 (62 on wire, 62 captured)
Ethernet II
Internet Protocol, Src Addr: 132.68.37.67 (132.68.37.67),
Dst Addr: 132.68.37.63 (132.68.37.63)
Stream Control Transmission Protocol
Source port: 5000
Destination port: 5000
Verification tag: 0x3a3c1af3
Adler-32 checksum: 0x49720413
(correct)
HEARTBEAT ACK chunk
Identifier: 5 (HEARTBEAT_ACK)
Flags:
0
Length:
16
Heartbeat
info parameter with 8 bytes of info
3.5. The chosen implementation modules description
Figure 4 - Major Modules of the SCTP implementation
Association Distribution Layer (c.f distribution) :
the main purpose of this module is the distrof signafrom thULP and fthe peer (via the socket and unix-interface) to the addressed association. On the receiving end signals from the Operating System-interface are always forwarded to the bundling module of the addressed association. Responsible of setting the correct association for the incoming or outgoing packets. Signals from the ULP are forwarded to SCTP-Control, Pathmanagement or Streamengine of the addressed association depending on the chunk type. All signals from the ULP contain the association ID, which is used to identify the association.
Adaption
Layer ( c.f adaption):
Responsible for the interaction with the Operating System. Manages thesockets and timers handling.
Flow
Control:
implements most parts of the flow control mechanisms such as congestion control, retransmission invocations, SACK creations etc.
Stream
Engine:
This module processes datastreams, sending and receiving datachunks. Responsible of assigning chunks to the correct streams and increases the TSN. On the sending side assigns the data into data chunks and passes on to the Flow Control.
Bundling:
Responsible for bundling chunks to messages on the sending side and rebundling messages to chunks on the receiving side.
4. Project tools and workspace
· Work environment: RedHat Linux 7.1
· Development and testing tools:
o Visual SlickEdit for Linux – essential for browsing unfamiliar code.
o Ethereal – A network sniffer with support for the SCTP protocol.
o NistNet - a network emulation package. Will be used to emulate a satellite like environment in order to test the project improvement.
5. The FEC implementation
5.1. Implementation issue I – FEC for packets or chunks
The first decision that we had to make regarding the FEC implementation was the data units that the FEC would apply for: packets or chunks. We chose to implement FEC for chunk because of the following reasons:
· For simplifying the implementation, we decided to use the TSN mechanism. This mechanism works per chunks, and there is no similar mechanism that works with packets.
· All the flow control mechanism of the protocol works with chunks. The FEC implementation improvements include integration of the FEC with the Flow control layer.
The main drawback of our decision is that packet contains one or more chunks, and always whole packets being lost. Thus, we would have in most of the cases burst of chunks that should be recovered. The solution to this drawback is to send one big chunk per packet, or use FEC interleaving algorithm.
5.2. Implementation issue II– Stream control or flow control
Another important decision regarding the implementation was in which layer of the protocol to implement the FEC.
We figured out that the best layer for the implementation is the flow control layer. In this layer we can delay retransmission of SACK chunk until the FEC chunk arrives, and by that to prevent unnecessary retransmission.
Nevertheless, We have implemented the FEC mechanism in the stream control layer for one basic reason: simplicity. The interaction with the flow control is part of the future improvements for our implementation.
5.3. FEC algorithm – sender side
Data structure:
SCTP_data_chunk_se fec_chunk – used to store the FEC chunk that will be sent in the end of the strip.
Algorithm:
· Every sent chunk is captured
· The captured chunk is xored with the fec chunk
· After sending ST_LENGTH chunks, the fec chunk is being sent
Note: The length field of the chunk is xored with the length field in the fec chunk header (for making the recovery of the lost chunk length possible).
5.4. FEC algorithm – receiver side
Data structure:
SCTP_data_chunk_se[ST_LENGTH + 1] – used to contain all the arriving chunks in a strip.
Algorithm:
· Every arriving chunk is captured and copied into the array
· When fec chunk arriving, there is a check if chunk recovery is needed and possible, and if so, it being performed.
· The recovered chunk is entered into the received chunks queue.
5.5.
Addition to the Bundling
module
In the Receiving end, the Bundling module must recognize
the FEC chunk. The recognition of the FEC chunk is done by using a unique chunk
Type value. We used Type Id 62 which was defined as Unused.
5.6. Current implementation status
The code writing was completed, but it hasn't been tested enough, due to problems with our testing environment (even the original implementation of SCTP, without any changes doesn't work!). We have managed to see, before the collapsing of our testing environment, that the FEC packet is being sent and received. We're not sure that the recovery phase is done completely, including transferring of the recovered chunk to the flow control layer.
5.7. Future enhancements
· A new version for the SCTP implementation is now
available:
sctplib-1.0.0-pre14. Applying the FEC patch
to this version may prevent the problems that we have encountered as described
in section 5.6.
· Multi Associations : SCTP as
described in RFC 2960 allows a single machine to establish several associations
distinctive one from each other by the verification tag and local ports,
characteristics which construct the common header of the SCTP packet. Obviously
FEC should be implemented per association. In order to calculate and maintain
the state of several FEC computations on a single host each local parameter such
as the index of the current packet sent or received in the FEC strip and local
FEC packet which is been computed should be kept in multiple instances and a
local key should be instantiated for each association.
For example: instead of holding a single variable as the
index in the strip, a array should be kept, and some sort of associations index
should be kept.
· The FEC mechanism should support unordered arrival of packets, that is permited by the protocol.
· As described in section 5.2, the FEC mechanism should be integrated with the flow control module