EFCP: RINA compared to SCTP

Nebiyu Feleke
Metropolitan College Boston University Email: naberra@bu.edu

Ben Ndrenika
Metropolitan College Boston University Email:Ndrenika@bu.edu

Assel Alimbekova
Metropolitan College Boston University Email: aasselya@bu.edu

Thanavit Cheevaprabhanant
Metropolitan College Boston University Email: Thanavit@bu.edu

AbstractThis is paper is done as a Mid-term project for CS-775, Advanced Computer Networking class. The objective of the paper is do a systematic analysis on the Error and Flow Control Protocol (EFCP) of two transport protocols, i.e. Stream Control Transport Protocol, SCTP and Recursive Inter-Network Architecture, RINA. SCTP is a recently developed transport protocol which is message oriented and designed to provide a reliable end-to-end communication between two peers in IP network. Whereas, RINA is a clean slate architecture which is designed to answer all the prevailing challenges of todays transport protocols, including TCP and SCTP. The paper starts with basics of Inter-Process communication between two distinct systems, based on the PNAs (Patterns of Network Architecture), and identies the mechanisms involved with Error and Flow Control protocol. Then, it makes a comparison between the policy implementations of RINA and SCTP and stipulates the policies that can be plugged-in to RINA.

Fig. 1.

Basics of communication between two systems

keeping it synchronized is not a straight forward process, many things could happen along the way, i.e.

I. BACKGROUND AND I NTRODUCTION Professor Day gave us assignment to compare and contrast EFCP policies of RINA and SCTP transport protocols and identify the polices that could be plugged-in to RINA. The rst thing we had to do was answer the questions, what is EFCP? What are the mechanisms of EFCP? What are the policies used by these mechanisms? In order to answer these questions and understand EFCP, the mechanisms and their policies, we decided to go back to the basics of communication between two protocol machines and work our way up to tackle the problem. We used Patterns in Network Architecture (PNA) model to discuss the basics of communication between two protocolmachines. The PNA model starts from the basics of two state machines communicating in a single system using a share state and extends the concept to two applications communicating in distinct systems using IPC facility. In essence, we found the PNA model to be an ideal Model which covers all the basics and also helps us to understand the mechanisms and policies behind Error and Flow Control Protocol. The model species that if two applications are running in distinct systems as shown in g 1, and they want to exchange information then they need some kind of mechanism which facilitates the message transfer. The exchange of data between A and B requires a distributed shared state among the nite state Machines (FSMs) using a distributed IPC facility. Once A establishes the distributed shared state with B, then the two systems can exchange their information using a protocol. However, creating the distributed shared state and

the message could get lost or corrupted while in transit which means it requires a lost and duplicate detection and retransmission mechanisms the sender might be ooding the receiver and the receiver should be able to tell the sender to send messages slowly which means it requires a ow control and congestion control mechanisms shared state between the two distinct systems should be synchronized which means it needs a synchronization mechanism

In summary, we need an Error and Flow Control Protocol (EFCP) which could address the above points and also guarantee the delivery of the actual message from one system to another. II. E RROR AND F LOW CONTROL PROTOCOL M ECHANISMS The error and ow control protocol should be able to transfer a message between two distinct systems and ensure the delivery of these messages. We found that the following mechanisms are mainly involved with EFCP, both in SCTP and RINA: a. b. c. d. e. Delimiting Sequencing and Ordering Fragment/Reassembly Flow control and congestion Retransmission

SDU Protection and Relay and Multiplexing can also be discussed here. However, we limit our discussion to Initial state synchronization, policies used for sequencing and ordering,polices used for ow control and congestion and polices

Fig. 3. Fig. 2. TCP/IP architecture and EFCP

RINA architecture and EFCP

used for Retransmission mechanisms, where we think there is a substantial difference which is useful to discuss. III. S TREAM C ONTROL T RANSMISSION P ROTOCOL SCTP is primarily designed to provide enhanced service over TCP and UDP transport protocols. The main services provided by SCTP, are end-to-end connection reliability using its Multi-homing feature and message streaming. In terms of error and ow mechanisms, EFCP of SCTP is similar to EFCP of TCP. Furthermore, SCTP assumes to use IP layer service and doesnt worry much about the sub-network below. Essentially, SCTP implementation of Error and Flow Control can be easily discussed using TCP/IP architecture. The initial design of TCP/IP was based on one protocol which provides end-to-end reliable connection service. However, as early as 1980s, it became obvious that some applications, i.e. XNET (cross-internet debugger) and real time digitized speech applications, didnt actually require end-toend reliable connection. These applications required a service which allows whatever gets through rather than a service that insists every byte sent to be delivered in order. Clearly, there was need for more than one transport service for the different applications that were coming out. Consequently, TCP/IP protocol architecture was split to two layers, i.e. TCP and IP layers. TCP assumed to provide the reliable sequenced data stream service while IP to provide the basic building block out of which variety of services could be built. This building block was referred as datagram. The datagram doesnt guarantee reliability, it works with best effort. Hence, it was possible to build a reliable (using acknowledging and retransmitting mechanisms) or unreliable (which is delay intolerant and doesnt concern about delivery) transport protocol over the datagram [7]. The split of TCP and IP was done as shown in Fig 2, where we noticed some of the error and ow control functions overlap between these two layers. IV. R ECURSIVE I NTERNETWORK A RCHITECTURE RINA architecture is an innovative architecture which was started from the basics of Inter process communication, IPC between two protocol state machines. John Day, the architect behind RINA, set out to answer the prevailing problems with TCP/IP architecture, which are mainly due to changes of service requirements by different applications. He also deduced that networking is IPC and only IPC and for two

distinct systems to communicate they use distributed IPC facility (DIF). RINA contends the direction to which TCP and IP were split. It states that a careful analysis of these protocols shows that the functions of error and ow control protocol cleave along lines of data transfer control and data transfer, as shown in g 3. The data transfer protocol (DTP) consists of tightly bound mechanisms which are mainly concerned with transferring user data, without any requirement of a control mechanism for reliable message delivery. DTP provides services for delay intolerant real-time applications such as video and voice applications. These applications are intolerant to any delay introduced by an overhead of data transfer control protocol. DTP roughly provides what IP and UDP provide. Data Transfer Control Protocol consists of loosely bound mechanisms and provides a reliable end-to-end connection for applications that requires it. DTCP provides retransmission, ow control and control congestion functionality. V. RINA EFCP AND SCTP EFCP A. Initial state Synchronization: The shared state between the two systems should be initialized before any data transfer starts. Generally, there are four forms of synchronizations [1] 1) Binding: creating of a local binding with (N+1) Protocol Machine and (N-1) Protocol Machine 2) Two Way Hand-shake: Binding and Two way hand shake Request, Response - doesnt have a feedback mechanism and commonly used by UDP 3) Three Way Hand shake: Binding and Three way handshake, i.e.Request, Response, and ACK , - has a feedback mechanism and commonly used by TCP 4) Delta-t (t): - a timer based synchronization mechanism. Delta-t states that the necessary and sufcient conditions for synchronization is to bound three timers, i.e. Maximum packet lifetime (MPL), Maximum time before ACK (A), Maximum number of retries (R). It assumes all connections exit all the time and there is no need use handshakes for synchronization. RINA uses this timer based mechanism to keep its distributed shared state (transport state) synchronized all time. TCP uses a three way handshake to overcome the TwoArmy problem and remain synchronized. However, it involves exchanging few messages, which also could be lost or get corrupted in the middle, to remain synchronized while RINA

Fig. 4.

Port allocation in RINA

SCTP is a message oriented protocol which uses a sequenced delivery within message streams. It uses this mechanism to bypass the strict sequenced delivery TCP while reordering messages or streams at the receiving end. SCTP includes these additional stream sequence numbers which could be used as SDU sequence numbers in QoS Cubes of RINA. C. Flow Control and congestion: SCTP is a general-purpose, connection oriented, unicast transport protocol which provides the reliable transport of user messages and a multi-homing concept out of the box. The SCTP congestion control combines the same TCP mechanism with extension to be compatible with multihoming and the modication for the message transfer rather than stream of bytes transfer. The sliding window control was specied with a modied version of TCP slow-start, congestion avoidance, fast retransmit and recovery mechanisms. Due to the similarity in congestion control mechanisms between TCP and SCTP, many works were done on SCTP congestion control in order to combine some of TCP control mechanism into SCTP control mechanism such as congestion window validation where it is also incorporated with SCTP. Another optional mechanism for TCP incorporated with SCTP is the use of Selective Acknowledgments (SACKs). Like TCP, SCTP supports ECN mechanism as an optional feature as a congestion notication. Standard SCTP never makes use of more than one path at the same time. Thus, the protocol state machine can handle one ow and one congestion control at a time during communications over either the actual path or the alternate one. In order to use all the available paths jointly, the original congestion and ow control of SCTP is to be modied. In SCTP, a single packet contains an header part and a payload containing user data. User data is organized in structures called chunks whose headers carry the Stream Identiers (Stream ID) and the Transmission Sequence Number (TSN) which is incremented for every chunk. For every association a Cumulative TSN (CTSN) is created at transmitter. CTSN stores the number of packets received in sequence and acknowledged by receiver. The receiver adopts the Selective ACKnowledgment (SACK) mechanism. The SACK packet contains the Cumulative TSN Ack Point (CTSN-AP) and some elds reserved to Gap Ack Blocks, representing the occurrences of the reception of packets with out-of order TSNs. CTSN-AP stores the highest in-sequence TSN already received. Typically, SACKs are sent every two in-sequence packets, but this is not a constraint. The Congestion Window (CWND) related to a path is incremented by transmitter when the two conditions are met: CTSN value is smaller than the TSN-AP reported by the SACK packet; and That SACK packet acknowledges data transmitted over that path 2. Packet loss detection is obtained through a modied version of the fast retransmit procedure of TCP Reno. When the

Fig. 5.

SCTP Association and Port Allocation

does it by bounding three timers and not involving a single message exchange. Delta-t is very imaginative and neat. Delta-t is the core of RINA which is used to decouple portids from being used in connection identiers, as shown in g 4. SCTP, TCP or any other transport protocol, if will, overload Port-ids in connection identier. This overloading of port allocation makes TCP/IP architecture more vulnerable to security threats than RINA[6]. 5) Cookie Mechanism: uses Binding and Four way Handshake, i.e. Request, Response, Cookie ECHO and Cookie ACK , and used by SCTP. The concept of four way handshake is not much different from the three way handshake of TCP/IP except that it adds additional handshake and protect the system from synchronization attack. SCTP uses associations for creating a shared state between endpoints during initial state synchronization. The concept of Associations slightly differs to the TCP connection. Association is composed of a set of IP addresses and port at a given time which is used to create a shared state between two end points. It is identied by a local handle called association id . A more precise denition would be an association A between two different generalized endpoints gE and gE is given by A = gE , S , gE , S Where S and S are a set of addresses at any time t such that S = Addr(gE ) = (IP 1, . . . , IP n , port ) S = Addr(gE ) = (IP 1 , . . . , IP n , port ) SCTP uses these set of IP addresses for an Endpoint as a failover addresses where the association with one IP addresses together with a port at a given time fails, then another IP address from the set could be used as a failover address to maintain the association between the endpoints. Essentially, SCTP provides a multi-homing service using the association concept. B. Sequencing and Ordering: RINA and SCTP use sequence number to number PDUs. The sequence numbers are also used for Sliding window mechanism.

TSNs are reported as missing for four consecutive, missing data chunks are retransmitted. In SCTP, fast retransmission of missing packets is performed only once and TCP-like fast recovery procedure turns useless. Standard SCTP adopts different congestion windows for each paths, but it never handles more CWNDs simultaneously. When several available paths are involved at the same time, the congestion windows could grow incorrectly. However, the most important problem to be solved for multiple path loads sharing in SCTP is the inability of the fast retransmission procedure to handle the high degree of packet misordering at the receiver side, generating useless packets retransmission and CWNDs halving. An SCTP connection between two peers is denoted as association. In an association, each peer is able to use multiple IP addresses which is called multi-homing. Each IP address of each peer endpoints denes a unidirectional path. In each direction, one of the paths is chosen as primary path. This designated path is actually utilized for the data transmission; the other paths are only used for retransmissions. Upon failure of the primary path, it may be switched to one of the backup paths. The user data is segmented into units of so-called DATA chunks. Each DATA chunk is identied by a unique Transmission Sequence Number (TSN). The receiver acknowledges the successful reception of DATA chunks by using a Selective Acknowledgement (SACK) chunk. Such a SACK chunk contains a cumulative acknowledgement (CumAck) which acknowledges all TSNs until a given TSN. It may furthermore acknowledge chunks above the CumAck in form of so-called GapAcks. This allows the sender instance to selectively retransmit only the particular chunks which are still missing in the reception sequence. A SACK chunk is sent back over the peer path of the last received DATA chunk packet. While CumAcks are obviously non-renegable it may revoke GapAcks. In order to improve efciency and to avoid retaining the non-outstanding GapAcked chunks in the send buffer the Non-Renegable SACK extension can be used to signalize nonrenegable GapAcks. Two different mechanisms are applied to handle retransmissions: Fast Retransmissions (Fast RTX) are used to retransmit a DATA chunk once, after being GapAcked for 3 times by default. Fast RTX occurs frequently, due to sporadic packet loss caused by concurrency. Timer-Based Retransmissions (Timer-Based RTX) are triggered by a timeout for any further retransmission. They should occur rarely and are usually a sign of severe congestion. SCTP applies window-based congestion control similar to TCP on each path, i.e. the amount of outstanding data is limited by the congestion window. D. Retransmission Control EFCP versus SCTP 1) Retransmission Timer: The Retransmission Control mechanism on RINA DTCP uses the Retransmission Timer which is a timer executed at the sender to determine when to retransmit PDUs that may have been lost or discarded.

The time interval, used by the Retransmission Timer, is based on an estimate by the sender of the time to get a positive acknowledgement of the PDU from the receiver. This time expiration interval value TR ( RTT + A)is generally a function of round-trip-time calculated by RTT Estimator Policy and thus must be coordinated with the Act and Ack List Policy. Logically, there are as many instances of this timer outstanding as unacknowledged messages. A Retransmission Timer instance is activated when a copy of Transfer PDU (i.e. DataPDU or SetContextPDU) that DTCP receives from the DTP is placed in the RetransmissionQ. If the timer expires before an AckPDU is received, all PDUs on the RetransmissionQ with sequence numbers less than or equal to the sequence number of the PDU associated with this time are re-sent. Instances of this timer are deactivated when the sender receive a positive AckPDU that covers it. The computation and management of RTO in SCTP follow closely how TCP manages its retransmission timer. To compute the current RTO, an endpoint maintains two state variables per destination transport address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation). An RTT measurement is made each round trip and is used to calculate the RTO in the following way: If no RTT measurement has been made, set RTO to the protocol paramete RTO.Initial. When the rst RTT measurement R has been made: 1) Set the smoothed RTT (SRTT) = R. 2) Set the RTT variance (RTTVAR) = R/2 3) Set RTO = SRTT + 4 * RTTVAR. When a new RTT measurement R has been made: 1) Set RT T V AR = (1 ) RT T V AR + |SRT T R | where = 1/4 2) Set SRT T = (1 ) SRT T + R where = 1/8. 3) Set RT O = SRT T + 4 RT T V AR. Whenever a data chunk is transmitted to any address, if the retransmission timer T3-rtx of that address is not running, the timer is started so that it will expire after RTO of that address. The retransmission timer is stopped whenever all outstanding data chunks have been acknowledged. Whenever a SACK is received that acknowledges the data chunk with the earliest outstanding TSN for that address, restart the T3-rtx timer for that address with its current RTO. If SACK indicates missing TSN that was previously acknowledged, start the T3-rtx for the destination address to which the data chunk was originally transmitted if it is not already running. When T3-rtx expire, SCTP will enter slow start by setting ssthresh to half of the current congestion window and the new congestion window to 1*MTU. The RINA DTCP Transmission Timer TR is generally a function of round-trip time similar to SCTP Retransmission Timer T3rtx, but the value of TR is calculated by RTT Estimator Policy, which is based on RTT and the Ack or Ack List Policy in use. Both RINA PNA TR timer and SCTP T3-rtx timer are started with similar event when the sender sends out a Transfer

PDU or DATA chunk. A PNA DTCP Retransmission Timer TR instance is started when a copy of Transfer PDU is put into RetransmissionQ (which is at the same time as the primary PDU is posted to RMT and RMT real-time sends out to the receiver) while SCTP T3-rtx starts whenever a data chunk is transmitted to each destination address. Both PNA TR timer and SCTP T3-rtx timer are stopped with similar event when the sender receives positive acknowledgement. 2) Acknowledgement: The acknowledgement mechanism in RINA and SCTP allow both selective and cumulative schemes. Both selective and cumulative acknowledgement scheme in RINA and SCTP operate and interpret in a very similar manner. In the cumulative acknowledgement scheme, SCTP uses SACK chunk with Cumulative TSN Ack parameter that contains the TSN of the last DATA chunk received in sequence before a gap. Slightly different from SCTP, RINA provides more options for its AckPDU to acknowledge not only positively but also negatively. In the accumulative fashion, RINA interprets retransmission operations based on a combination of Ack/Nack ag (one out of two ags in the PDUType opcode eld) and Ack/Nack eld. To have positively acknowledged, Ack/Nack ag is set to true, then the sender will delete all PDUs from the ReTransmissionQ with SequenceNumbers less than or equal to the contents of the Ack/Nack eld and discontinue any Retransmission Timers associated with these PDUs. Otherwise (the Ack/Nack eld is interpreted as a Nack), the sender will retransmit all PDUs on the RetransmissionQ with SequenceNumbers greater than or equal to the contents of the Ack/Nack eld. In the selective acknowledgement scheme, SCTP uses SACK to acknowledge the receipt of data chunks. A SACK chunk does in addition to the specic chunk headers consist of the cumulative TSN and the size of the advertised receiver window. A SACK chunk consists of several Gap Ack blocks, denoting received chunks when there are holes in the data chunk sequence. Each Gap Ack block contains the offset number of the rst TSN and last TSN of a continuous block of data chunks. The TSNs can be found by adding the offset number to the cumulative TSN. At last, a SACK chunk consists of blocks of duplicate TSNs. Multiple blocks of SACK information can get bundled into one packet as long as the total size of the packet does not exceed the network MTU. In the absence of loss, a SACK is sent back for every second packet received or within 200 ms of the arrival of any unacknowledged data chunks. If one or more holes in the received data chunk sequence are detected, the receiver will immediately send a SACK back for every incoming packet until the data chunk sequence is restored. RINA uses selective acknowledgement mechanism with the same AckPDU structure that used in the cumulative scheme but using additionally with Ack/Nack List ag (one out of two ags in the PDUType opcode eld), Ack/Nack List Length eld, and Ack/Nack List eld. If the Ack/Nack List Length is

non-zero, then there are selective acks or nacks depending on the value of the Ack/Nack List ag. If the Ack/Nack List ag is true then, the PDUs designated by the ranges of SequenceNumbers indicated by the Ack/Nack List are deleted from the RetransmissionQ and any timers associated with these PDUs are discontinued. Otherwise (the Ack/Nack List is interpreted as a Nack), the PDUs from those ranges are retransmitted. Note that since one can never know whether a retransmitted PDU arrives, a Negative Ack can never cause PDUs to be removed from the RetransmissionQ. Similarly, SACK chunk in SCTP includes ranges of missing or lost DATA chunks to have selectively negative acknowledged by identifying as pairs of Gap Ack Block Start and Gap Ack Block End that associated with ranges of TSNs of DATA chunks. AckPDU in RINA includes ranges of missing or lost Transfer PDUs to have selectively negative acknowledged by identifying as pairs of StartingSeqNbr and EndingSeqNbr that associated with ranges of sequence numbers of Transfer PDUs. 3) Retransmission: When the sender receives acknowledgement that indicates there are some missing or lost packets, RINA and SCTP determine which data to be retransmitted in similar way but with different number of feedback packets they collect information. RINA determines which data to be retransmitted and respond to each feedback protocol unit (AckPDU) while SCTP collect information from four feedback packets and respond at the fourth feedback protocol unit (SACK chunk). At each response to an AckPDU, RINA allows the sender to retransmit in two options: all PDUs less than or equal to attached SequenceNumber or a range of sequence numbers, then recalculate RTT for each TR timer instance associated with particular SequenceNumber in RetransmissionQ. By waiting for four consecutive SACKs, SCTP tries to reduce retransmissions caused by packets that are received out of order. Whenever SCTP sender receives a SACK that reports missing data chunks, it will wait for four consecutive SACKs reporting that the same data chunks as missing before going to fast retransmit. The sender marks all missing data chunks reported by four SACKs for fast retransmit. The retransmission timer restarts only if the last SACK acknowledged the earliest outstanding data chunk or the sender retransmitting the rst outstanding data chunk. When the sender does not receive acknowledgement and the retransmission timer expires, RINA will retransmit all Transfer PDUs in the RetransmissionQ that have sequence numbers less than or equal to the SequenceNumber contained in that expired TR timer instance and recalculate RTT for all TR timer instances associated with each PDU. After a retransmission timeout, SCTP will enter slow start by setting ssthresh to half of current congestion window and new congestion window to 1*MTU. The RTO is set to 2*RTO for a destination address for which the timer expired. The number of earliest outstanding data chunks for the address for which the timer expired is determined and bundled into a single packet and this packet retransmitted to that address.

R EFERENCES
[1] J. Day, Patterns in Network Architecture,Prentice hall, 2008 [2] R. Stewart,Stream Control Transmission Protocol, RFC 4960, September 2007. [3] A. s. Tanenbaum,Computer Networks, 5th Edition.Prentice hall, 2011 [4] R. Watson,Timer-Based Mechanisms in Reliable Transport Protocol Connection Management,Computer Networks, vol. 5, pp. 4756, 1981. [5] R. Stewart et al.,Stream Control Transmission Protocol Dynamic Address Reconguration, RFC 5061,September 2007. [6] G. Boddapati, J. Day,I. Matta,L. Chitkushev, Assessing he security of a clean-slate internet Architecture,Dec 2010 [7] D. D. Clark,The design philosophy of the DARPA Internet Protocols,SIGCOMM 88 , Computer Communication Review Vol.18, No.4 August 1988, pp 106-114 [8] J. Day, I. Matta and K. Mattar,Networking is IPC: A Guiding Principle to a Better Internet,in Proceedings of ReArch08 - Re-Architecting the Internet. Madrid, SPAIN: Co-located with ACM CoNEXT 2008, December 2008. [9] R. stwart, M. Tuxen, P. Lei,SCTP:What is it, and How to use it?,