B M XTP A F CHAPTER V

CHAPTER V

A PPLICATION OF THE F ^UNCTION B ASED M ETHODOLOGY TO XTP

V . 1 . I

N T R O D U C T I O N

The aim of this chapter is to apply the Function Based Methodology proposed in the previous chapter to an existing protocol. We have selected Xpress Transfer Protocol (XTP) [36, 91, 92] for several reasons. First, XTP is a modern transport protocol designed as a high performance protocol to provide new services useful to current and emerging distributed applications. It spans over the network layer and transport layer. Indeed, layers integration is considered as a new trend of high-speed transport protocols. Second, XTP provides a rich set of protocol functions from which the XTP user can select the configuration that supports its needs and which will govern the data exchange. Finally, in creating XTP, its designers have taken into account the state of the art in the protocol engineering and the lessons learned from the experience of the other protocol designs and implementations.

The chapter is organized as follows. Section V.2 describes the XTP protocol. All features necessary to the application of the methodology are reported. The remaining characteristics and details are omitted. Section V.3 presents an XTP

model which follows all the steps developed by the methodology detailed in the previous chapter. Section V.4 shows how XTP can be configured in order to furnish two types of services. Finally, a conclusion is drawn.

V . 2 . X T P D

E S C R I P T I O N

XTP is a recent transport protocol being designed for implementation in a specialized VLSI architecture called Protocol Engine (PE). XTP was designed in the late eighties as a high performance protocol to provide new services useful to current and emerging distributed applications. It integrates the Network layer and Transport layer functionalities defined by the Open Systems Interconnection (OSI) Reference Model. This integration reduces overhead introduced by layered communication architectures, and redundant functionalities being processed in several layers are avoided.

Actually, by streamlining the protocol, combining the transport and network layers¹ and utilizing the increased speed and parallelization possible with VLSI implementation, XTP is able to provide the end-to-end data transmission rates demanded in high speed networks without compromising reliability and functionality.

XTP provides a rich set of protocol functions from which the XTP user selects the configuration that supports its needs and which will govern the data exchange. In other words, XTP provides functions and mechanisms; the user selects policy, since XTP assumes that the user knows best how to optimize the parameters of its connections. In order to succeed in this strategy, XTP provides selectable options such as : selectable error control options, selectable flow control options, selectable acknowledgment options, and selectable retransmission options.

On the other hand, XTP requires from the underlying data delivery service to provide only a few basic services : data integrity, a simple framing capability, and a data delivery service between hosts on the same physical network segment.

In a LAN environment, XTP is satisfied with the services offered by, for

1 The single layer which combines the functionalities of both the network and transport layers of the ISO OSI model is called transfer layer.

example, IEEE 802 LLC type I. XTP packets must be placed in the protocol data units of the underlying data delivery service.

XTP can support different types of services required by distributed systems. In particular, the implicit connection setup can be used to support connectionless types of services. The selective error control makes it feasible to offer both reliable and unreliable services. Six different types of services have been predefined : (1) stream, (2) transaction, (3) unacknowledged datagram, (4) acknowledged datagram, (5) isochronous stream, and (6) bulk data. Sub-section V.2.3. presents these services.

V . 2 . 1 . X T P P a c k e t s

An XTP packet has three main segments : the Header, the Trailer, and the Middle Segment. The header and trailer² have fixed format and syntax. The middle segment, however, is variable to allow the XTP packet to contain different types of information. The middle segment consists of one of the two segment formats, the Control Segment format or the Information Segment format. The control segment provides the mechanisms to communicate any necessary state information from one protocol entity to another one. The information segment provides mechanisms for communication of user or protocol data, rather than protocol state information. If the data is provided by the user as payload, it remains uninspected from end-to-end. If the data is protocol-provided, it may be both examined by the protocol and given to the user. Also included within this segment are mechanisms for providing addressing information. The information segment is therefore composed of sub-segments for each special purpose.

User data is placed in a format called a Data Segment. Addressing is likewise placed in a format called an Address Segment. Three variations of the information segment format are combinations of these two sub-segments: an address segment along with a data segment, an address segment alone, and a data segment alone. The fourth variation of the information segment is the management segment, used specifically for the protocol-provided data exchange.

It never contains an address segment or a user-provided data segment.

2 The trailer consists of a single field : dcheck field, a data checksum.

Figure V.1 : General XTP packet structure

Header (40) Middle Segment (4*n) Trailer (4)

Control Segment

Information Segment - Data Segment

- Address Segment

- Address Segment + Data Segment - Management Segment

There are nine formats for XTP packets. Two of them specify that the middle segment is a control segment. The remaining seven specify that the middle segment is an information segment.

In this chapter, only DATA and CNTL packets are considered. Briefly, the DATA packet is used to exchange user data. The CNTL packet facilitates protocol status exchanges between endpoints.

V . 2 . 1 . 1 . X T P H e a d e r

All XTP packets contain a common group of fields called the packet header. The header contains ten 4-byte fields. In here, we consider four fields: dlen, seq, dseq, and cmd fields (figure V.1).

Dlen contains the length of the middle segment, excluding alignment bytes. Seq values represent byte sequence numbers associated with one simplex data stream.

Seq values do not include padding bytes as defined by the offset field. The seq value of an output packet is obtained using the following formula where retransmissions are ignored :

seq = previous seq + size of previous information segment - any padding.

The delivered sequence number (dseq) field indicates how much data has been received and delivered to the XTP user.

The cmd field encodes mainly three kinds of information within three subfields (figure V.2) : (1) the various protocol options chosen by the association endpoint that generates the packet, (2) the number of bytes of offset before the beginning of user data (if any is present), and (3) the format of the remainder of this packet.

The offset subfield specifies the size in bytes of optional padding at every beginning of the information segment. This subfield can be used to extend a packet to meet a minimum size requirement, or for an alignment that enables efficient data copying. The ptype subfield specifies mainly the format of the XTP packet. As described before, there are nine formats for XTP packets.

Figure V.2 : cmd field in the XTP header

NOERR RES NOFLOW FASTNACK SREQ EOM BTAG Others

cmd

Options Offset ptype

XTP Header dlen seq dseq

The options subfield controls many service features of the protocol. Each option may be independently set, although some options preclude others. The NOERR bit indicates that no error mode is in effect. When this option is set, it turns off certain error recovery procedures at the receiver. The RES bit indicates reservation mode. Reservation mode requires from the receiver to throttle the transmitter such that the transmitter never sends more data than will fit in the buffer space reserved at the receiver. The NOFLOW bit indicates no flow mode.

The transmitter can then ignore flow control constraints on its outgoing data stream. The FASTNAK bit indicates that a receiver should generate a FAST negative acknowledgment immediately when out-of-sequence data are detected.

The SREQ bit is used to request the generation of a CNTL packet from an association endpoint. The EOM bit marks a particular point in the data stream as the end of a message. When set, the BTAG bit (for Beginning TAG) indicates that the first 8 bytes of user data in the Data Segment of a packet are “tagged”.

This tagging is not interpreted by XTP; the user is simply notified of the fact that

the data is tagged, and it is the responsibility of the user to know how to interpret tagged data.

V . 2 . 1 . 2 . C o n t r o l S e g m e n t

The fields within the control segment represent the mechanisms that CNTL packets employ to communicate protocol state information between protocol entities. Control segments are of variable length, however their syntax guarantees that the length will be a multiple of 8 bytes. Figure V.3 shows the main fields in a control segment.

Figure V.3 : Main fields of control segment rate burst alloc rseq nspan spans Others

Control Segment

The rate and burst fields carry the values that govern the rate control algorithms.

The alloc, rseq, nspan, and spans fields carry values for the flow control and error recovery procedures, providing received data information and retransmission request information.

The value of the rate field represents the maximum number of bytes per second that the transmitter can send on average over a period of time. The rate value, therefore, dictates a spacing between bursts of data. A rate value of 0 completely halts any transmission of bytes from the sequence space. The burst field contains the maximum number of bytes that a node can handle in any single packet burst.

A burst value of 0 turns off rate control, allowing the machine to transmit at will.

The alloc field conveys to the transmitter the highest sequence number that the receiver is able to consume. In this way the receiver can impose flow control upon the transmitter. The value in the rseq field is one plus the highest sequence number for which all bytes with smaller sequence numbers have been received on this data stream. The spans field consists of pairs of sequence numbers defining unbroken sequences of received data within a data stream after rseq.

Each pair occupies 8 bytes. The pairs must be in order so that they describe sequentially ordered spans.

V . 2 . 1 . 3 . D a t a S e g m e n t

The Data Segment is always present in DATA packets. Figure V.4 shows the field structure of the data segment, consisting of the data field and an optional btag field. The data field is the mechanism for transferring uninterpreted user data. The XTP user may place 8-bytes tagged data (btag field) in the data stream.

If present, tagged data is always carried in the first 8 bytes of the data segment.

Figure V.4 : Information Segment : Data Segment Padding Data Segment Alignment

Information Segment

Btag data

V . 2 . 2 . P r o t o c o l T r a n s f e r F u n c t i o n s

V . 2 . 2 . 1 . S e l e c t a b l e E r r o r C o n t r o l F u n c t i o n s

In order to provide a data transfer service that claims to be reliable, there must be procedures present in the service provider that can monitor the data transfer and supporting procedures that detect, notify, and, if possible, recover any error conditions that may arise. The error control procedures within XTP are designed to facilitate reliable data transfer.

V.2.2.1.1. Acknowledgment

XTP allows the transmitter to decide whether and when acknowledgments are desirable. Within XTP, the transmitter is in control. Receivers do what they are asked to do, when they are asked to do it, but in general they do not provide

information that is not requested. A receiver transmits a CNTL packet in two cases :

1. Whenever the receiver responds to a received sreq, or

2. If the FASTNAK bit is set, the receiver does so immediately upon detecting an input data stream sequence gap. This is used when out-of-sequence data implies lost data.

Case (1) is the normal and a conservative case that is compatible with the out-of- order packet arrival. Case (2) represents a quicker-acting (more aggressive) error control policy that is possible only when out-of-order packet delivery is not possible. The FASTNAK bit enables the quicker error control policy.

V.2.2.1.2. Retransmission

XTP implements go-back-n, but in addition permits a potentially more efficient scheme called selective retransmission.

Go-back-n retransmission is a simple retransmission technique wherein output is restarted from an earlier point in the output stream before errors were observed at the receiver. This technique does not discriminate between retransmission of missing or damaged packets and duplicate transmission of undamaged packets if both kinds of packets are included in the go-back-n sequence number range.

Besides, selective retransmission is an error control technique wherein only damaged or lost packets are resent. A receiver must store out-of-order packets, advice the sender of the data that needs to be resent, and reorder the data stream or buffer area as retransmitted packets arrive. In this case, the receiver provides a vector indicating what spans³ of information have been correctly received, and the sender can then retransmit only the gaps.

On the other hand, the retransmission scheme can be disabled when the sender sets the NOERR bit. In this case, correctly received data are properly sequenced, but gaps are not retransmitted, which is useful for digital voice and video.

Remark

Maintaining selective acknowledgment queues, tracking spans and gaps, can lead to considerable complexity and overhead. This overhead can be justified when

3 A span is a contiguous group of data.

there are high network error rates coupled with low bandwidth transmission or long propagation delays. In these circumstances, overall network throughput can be improved by selective acknowledgment. However, in high bandwidth, low delay and low error rate networks, there may be no detectable performance difference using selective retransmission or using simple go-back-n.

Retransmission on timeout

The sender defines a timer, wtimer : wait interval or wait timer value. Wtimer detects when requested CNTL packets are not received within the expected period. Wtimer is started whenever a packet containing sreq is sent. The value for wtimer should be no less than the current RTT⁴, and includes a factor accounting for system queueing delays. Setting wtimer equal to twice the estimated RTT is a reasonable place to start.

When wtimer expires, one of the following conditions should hold:

1. CNTL messages were received and indicated no errors 2. CNTL messages were received and errors are indicated 3. No CNTL messages were received during the timer interval.

No action is needed in case (1). In case (2) the contents of the CNTL packet indicate the number of gaps (nspan) and which spans of output sequence numbers have been received. In case (3) the sender begins to send unacknowledged messages.

Wtimer is determined by applying the smoothing procedure suggested by Van Jacobson [74] to the RTT values obtained from any XTP control handshake. The XTP defines two variables, SRTT and RTTV, to be the smoothed RTT and the RTT Variance, respectively. SRTT is initialized to a default RTT; RTTV is initially 0. For each new RTT measurement, the following formulas are computed:

SRTT := SRTT + (RTT - SRTT)/8

RTTV := RTTV + (⏐RTT - SRTT⏐ - RTTV)/4

4 Round Trip Time : the time between when a sender transmits a packet and when it receives an acknowledgment for that packet.

The wtimer is set to the smoothed RTT value plus twice the variance in the round-trip time measurement: wtimer := SRTT + 2 * RTTV.

V . 2 . 2 . 2 . S e l e c t a b l e F l o w C o n t r o l F u n c t i o n

Flow control is a method of regulating the volume of information that may be sent. XTP provides three types of flow control:

1. Ordinary flow control based on fixed sliding window mechanism.

2. Conservative flow control based on credit scheme. The credit scheme also uses a sliding window, but the window is now of variable size. The size is controlled by a credit parameter (alloc field) in the CNTL packets. In order to use this type of flow control, the receiver has to set the RES bit (reservation mode).

3. NOFLOW option disables flow control entirely It is useful for multimedia applications.

V . 2 . 2 . 3 . S e l e c t a b l e R a t e C o n t r o l F u n c t i o n

Rate control is the technique of limiting the rate at which a sender is allowed to transmit data, and the amount of data transmitted at one time. Rate control can limit congestion in the center of a network, i.e., at gateways, as well as limiting overruns at receivers.

The output packet rate is regulated by two variables (credit and burst), and a refresh timer (rtimer). These variables are calculated from the rate and burst fields received in CNTL packets. The rate value specifies the maximum data rate in bytes per second. The burst value specifies the maximum number of bytes to be sent in a burst of packets. Rate divided by burst gives the number of burst size transmissions per second or credit. Burst divided by rate gives the time period for rtimer.

Upon each expiration of rtimer, the internal variable “credit” is loaded with the value burst. Alternatively credit is loaded approximately as rate/burst times per second. Credit is decremented by the size of each output transmission. Output is permitted as long as credit remains greater than zero, and is suspended when

credit becomes zero or negative. The suspended state lasts until credit is refreshed at the next rtimer interval.

V . 2 . 2 . 4 . F r a g m e n t a t i o n / C o a l e s c e n c e F u n c t i o n s

Fragmentation is the operation of breaking a DATA packet into smaller ones.

Fragmentation is necessary when the underlying subnetwork cannot handle a packet larger than a certain size, called maximum transmission unit (MTU).

Once a packet has been fragmented, it remains that way while it travels through the network. If a packet is split into 4 smaller ones, the information segment is split into 4 parts, and a new header and trailer are constructed for each smaller packet. Coalescence⁵ function is the inverse of fragmentation, whereby packets are grouped to form larger packets.

V . 2 . 3 . S e r v i c e s P r o v i d e d b y X T P

XTP can support different types of services required by distributed systems. Six different types have been predefined:

1. Stream: XTP implements the traditional stream service by means of full- duplex virtual circuits (connections). At each side of the connection, a context is defined and maintained to keep track of the state variables collectively at each side. This service is the same as provided by TCP or OSI TP 4.

2. Transaction: a transaction is initiated by a client entity sending a request message to a server entity and terminated by the server sending back a response message. If the response arrives, it implicitly acknowledges the receipt of the request. Otherwise, the client times out and retransmits the request message. The client retransmits the request periodically, giving up in failure if no response is received after some number of retransmissions.

3. Acknowledged datagram: Datagram service is implemented by means of short lived connections. Connections for stream data transfer are created in real time by sending a FIRST packet. Datagrams are created in the same way, but the connection is released right after the FIRST packet. The FIRST packet can

5 Called also reassembly

carry user data. In order to signify to the receiver that no more packets will arrive, in the header of the FIRST packet, the wclose bit is set which indicates that the sender is closing the operation and is not sending consecutive packets.

Since the error correction mechanism is active with virtual circuits, this provides a reliable real-time datagram service.

4. Unacknowledged datagram : It is possible to disable the error correction mechanisms, thereby creating an unreliable datagram service as performed by a connectionless service.

5. Bulk data: this service is achieved by using the reservation mode (the RES bit is set). To implement bulk data transfer, the sender first requests from the receiver to reserve actual client buffer space, and the receiver responds with a control packet which indicates the amount of reserved buffer space (alloc field). Reservation mode is used to avoid overflowing of the receiver buffers because of bulk transfers.

6. Isochronous stream: this service support a continuous stream generation which has delay and delay jitter requirements. However, it can tolerate some amount of data loss. An isochronous stream requires synchronization between the sender and the receiver. In order to provide a traffic shaping leading to continuous transmissions, XTP adjusts parameters associated with the rate control function. Indeed, rate control is recognized as a technique for enforcing policies, performance optimization and resources usage control across the specific media of the application [93]. As explained before, XTP rate control is based on three parameters : burst, rate and rate control timer (rtimer) interval. Burst specifies the maximum number of bytes allowed to be sent in a rtimer interval. Rtimer interval can be obtained as : rtimer = burst/

rate. On the other hand, XTP disables the recovery functions (NOERR option), the flow control (NOFLOW option) and the checksum calculation (NOCHECK option).

V . 3 . X T P M

O D E L

In this section, the principal features of the XTP model are detailed according to the function based methodology developed in the fourth chapter. First, the data structures associated with the events and the protocol entity are defined.

Secondly, a sub-set of XTP functions are described using the syntax previously

defined. The two remaining parts give the precedence graphs and the -Graph.

For simplicity, only pertinent information is defined.

V . 3 . 1 . D a t a S t r u c t u r e s

The data structure associated with the event “arrival of message” contains two elements of important information: the length of the message and the address of its destination. The events “arrival of a DATA packet” and “arrival of CNTL”

are associated with the data structures DATA_PACKET and CNTL_PACKET respectively. The two data structures contain the object HEADER. The names of the fields contained in these data structures are the same as for the DATA and CNTL packets presented in section V.2, except “nspan_begin” and “nspan_end”

which contain the begins and ends of the packets stream gaps.

The data structure associated with a protocol entity is contained in the object CONTEXT. It contains information necessary for the numbering function (num_seq field), for flow control (win_length, left_edge, right_edge, credit_c, and Q_frag_af_FC fields), for rate control (rate, burst, burst_c, rtimer and Q_frag_af_RC fields), for fragmentation (MTU and Q_frag fields), for RTT estimation (SRTT, RTT, and RTTV fields), for resequencing (Q_frag_not_seq field), and for retransmission functions (Q_frag_ret and wtimer fields).

EVENT MESSAGE; & data structure associated with the event “arrival of a message BEGIN & from the AL”

INTEGER length_msg; & length of the message INTEGER address_receiver; & address of the receiver END;

OBJECT HEADER;

BEGIN INTEGER dlen, seq, dseq;

BOOLEAN NOERR, RES, NOFLOW;

BOOLEAN FASTNACK, SREQ, EOM, BTAG;

END;

EVENT DATA_PACKET & data structure associated with the event “arrival of a BEGIN & DATA packet from the NL”

HEADER hdata;

INTEGER length_padding;

END;

EVENT CNTL_PACKET; & data structure associated with the event “arrival of a

BEGIN HEADER hcntl; & CNTL packet from the NL”

INTEGER rate, burst, alloc, rseq, nspan;

INTEGER nspan_begin(nspan), nspan_end(nspan);

END;

OBJECT CONTEXT; & object containing the data structure of a protocol entity BEGIN

INTEGER MTU, num_seq, rate, burst, burst_c;

INTEGER win_length, left_edge, right_edge, credit_c;

REAL SRTT, RTT, RTTV, wtimer, rtimer;

POINTER Q_frag; & queue containing fragments

& queues containing fragments to transfer after Flow Control or Rate Control QUEUE Q_frag_af_FC;

QUEUE Q_frag_af_RC;

QUEUE Q_frag_not_seq; & queue containing not sequenced fragments QUEUE Q_frag_ret; & queue containing retained fragments END;

V . 3 . 2 . D e s c r i p t i o n o f F u n c t i o n s

The library of functions associated with XTP is partitioned into three parts called Fmess, Ftimer and Fpack. Fmess contains the functions which may be executed if a message arrives from the application layer. Ftimer contains only one function which is go-back-n on wtimer. Finally, Fpack contains functions which may be executed when either a DATA packet or a CNTL packet arrives from the sub- network. The contents of these three parts are :

Fmess = {fragmentation, flow control, rate control, padding, numbering, retention, transfer DATA}

Ftimer = {go-back-n on wtimer}

Fpack ={coalesce, un-padding, resequencing⁶, retransmission, rtt estimation, transfer message, transfer CNTL}.

Hereafter, we describe a sub-set of functions, mainly those contained in Fmess.

As a reminder: (1) the sets IN(v) and IN(e) contain the inputs of the function, which can be found in the data structure of the event and the data structure of the protocol entity, respectively; (2) the set OUT(v) and OUT(e) contain the outputs of the function, which can be found in the data structure of the event and the data

6 Also called reordering

structure of the protocol entity, respectively; (3) MEAS(l) contains the local measurements associated with the function. When a function is associated with only one algorithm, the CHOICE block is omitted.

& Fragmentation function cuts a message (if necessary) into fragments of length

& MTU. The fragments are contained in Q_frag Fragmentation ;

BEGIN

IN(v) = length_msg;

IN(e) = MTU;

OUT(e) = Q_frag;

MEAS(l) = num_frag, & number of fragments

mean_frag_msg; & mean number of fragments per message frag_module;

END;

Numbering ; & it numbers each fragment contained into Q_frag BEGIN

IN(e) = Q_frag, num_seq;

OUT(e) = Q_frag(seq)⁷, num_seq;

num_module;

END;

& all the fragments which can be transferred are added to Q_frag_af_FC Flow_control (Algorithm);

CHOICE

credit : BEGIN & credit scheme

IN(e) = Q_frag, credit_c;

OUT(e)= Q_frag_af_FC, credit_c;

credit_module;

END;

SW : BEGIN & Sliding_Window algorithm

IN(e) = win_length, left_edge, right_edge, Q_frag;

OUT(e) = Q_frag_af_FC, Q_frag, left_edge;

MEAS(l) = window_usage;

SW_module;

END;

END;

& all the fragments which can be transferred are added to Q_frag_af_RC Rate_control ;

7 This notation means that “all seq fields of all fragments contained in Q_frag” will be updated

BEGIN

IN(e) = rate, burst_c, Q_frag, Q_frag_af_FC;

OUT(e) = burst_c, Q_frag, Q_frag_af_FC, Q_frag_af_RC;

rate_module;

END;

& Padding function adds a certain number of octets to make the length of fragments

& contained in Q_frag a multiple of 4 Padding ;

BEGIN

IN(e) = Q_frag;

OUT(e) = Q_frag(length_padding);

MEAS(l) = total_number_of_added_octets,

mean_number_of_added_octet_per_frag, mean_ratio_of_padding⁸;

pad_module;

END;

& retain fragments stored, in Q_frag_af_RC if not empty, otherwise in Q_frag_af_FC if

& not empty, otherwise in Q_frag Retention ;

BEGIN

IN(e) = Q_frag, Q_frag_af_FC, Q_frag_af_RC;

IN(v) = address_receiver;

IN(e) = Q_frag_ret;

OUT(e) = Q_frag_ret;

ret_module;

END;

Retransmission (Algorithm);

CHOICE

go_back_n : BEGIN

IN(e) = Q_frag_ret, left_edge;

OUT(e) = Q_frag_af_FC;

MEAS(l) = num_ret; & number of retransmission go_module;

END;

selective : BEGIN

IN(e) = Q_frag_ret, nspan, nspan_begin, nspan_end;

OUT(e) = Q_frag_af_FC;

MEAS(l) = num_ret;

selec_module;

END;

8 Padding ratio = number of added octets divided by the length of the fragment

END;

& transfer fragments stored, in Q_frag_af_RC if not empty, otherwise in Q_frag_af_FC

& if not empty, otherwise in Q_frag Transfer_DT;

BEGIN

IN(v) = address_receiver;

IN(e) = Q_frag, Q_frag_af_FC, Q_frag_af_RC;

OUT(e) = Q_frag, Q_frag_af_FC, Q_frag_af_RC;

MEAS(l) = num_frag; & number of transferred fragments Trans_module;

END;

V . 3 . 3 . P r e c e d e n c e G r a p h s

When a message arrives at the sending part of an XTP entity, it is fragmented (if necessary). Each fragment can be numbered, retained, and aligned in order to have a length multiple of 4. Flow and rate controls may defer the transmission of fragments. Figure V.5 shows the precedence graph associated with the set of functions, Fmess. Fragmentation and Transfer DT are prerequisite functions. The retention function has to be executed before Rate/flow controls and numbering functions. Indeed, only fragments which can be transferred are retained. The padding function has to be executed before a fragment is retained or transferred.

A possible sequence of the precedence graph associated with Fmess is :

<Fragmentation, Numbering, Flow control, Rate control, Padding, Retention, Transfer DATA>.

Figure V.7 shows the precedence graph associated with Fpack. The coalesce function is a prerequisite function. If a DATA packet arrives, the added octets (if any) are removed by the un-padding function. Some error controls will be done such as resequencing. Then, the coalesce function is performed and if necessary a CNTL packet is transferred. The transfer message function is associated with two algorithms. The first one transfers a reassembled message to the application above the XTP entity. The second algorithm is used when a timing synchronization is needed. If a CNTL packet arrives, a new value of RTT is estimated, and if asked by the receiver entity, selective retransmission is performed to send gaps determined by the receiver.

A possible sequence of the precedence graph associated with Fpack is :

<Un-padding, Resequencing, Coalesce, Transfer CNTL, Transfer Message, RTT estimation, Selective retransmission>.

Since Ftimer contains only go-back-n on wtimer function, its corresponding precedence graph is straightforward (figure V.6).

Figure V.5 : Precedence graph of Fmess Fragmentation

Flow control

Rate control

Padding Numbering

Retention

Transfer DATA Begin

End

L

^*1

Begin

Go-back-n on wtimer 181

Figure V.6 : Precedence graph of Ftimer

Figure V.7 : Precedence graph of Fpack Begin

V . 3 . 4 . - G r a p h

The prerequisite functions, fragmentation and coalesce, have both to belong to any two peer-protocol entities patterns. Thus, these functions are linked by a Λ-labeled edge. If the resequencing function has to belong to the receiving part

Coalesce

Resequencing Retransmission

Un-padding

RTT estimation

Transfer Message Transfer CNTL

L

^1*

End

of a protocol entity pattern then the packets have to be numbered. Hence, the numbering function has to be present in the sending part of the peer-entity. For this reason, in the -Graph (figure V.8) associated with the XTP functions, there is a Λ-labeled arc, coming from the resequencing function and arriving to the numbering function. The presence of the Λ-labeled arc between the padding function and the un-padding function is obvious. If null octets have to be added to a packet, they have to be removed after the arrival of the packet at its destination. We assume that if the retention function is asked to be part of a protocol entity pattern then the retained packets will be used afterwards, and if necessary, when one or several packets have to be retransmitted. In this case, the go-back-n on wtimer function has also to be present in the same protocol entity pattern, this is why a Γ-labeled edge exists in the -Graph. On the other hand, if the retransmission function is selected, the numbering function has to be present in the same protocol entity pattern. For this reason, a Γ-labeled arc exists in the -Graph, exiting from retransmission function and entering to retention function.

Fmess Ftimer Fpack Figure V.8 : -Graph

Fragmentation

Flow control Rate control

Padding Numbering

Retention

Transfer DATA

Coalesce

Resequencing

Retransmission Un-padding

RTT estimation

Transfer CNTL

Λ

Γ

^*1

Γ

go-back-n on

wtimer

Λ

Λ

V . 4 . X T P P

A T T E R N S F O R T W O

S

E R V I C E

C

L A S S E S

Let us consider a mono-directional communication between a sending entity and a receiving entity. The protocol patterns of these two entities depend on the service provided to an application. In this section, we will show how XTP can be configured in order to provide two types of its pre-defined services : stream and isochronous stream services.

V . 4 . 1 . X T P P r o v i d i n g a S t r e a m S e r v i c e

Stream Service is also known as non-real time reliable service. It can be provided, for example, to the file transfer applications. Indeed, these applications require that the underlying service is reliable and all their data have to arrive in sequence and error-free. However, they have no stringent requirements on delay or throughput. Figure V.9 shows the patterns of two peer-entities providing a stream service. We note that error recovery functions are present, and the message transfer function is associated with its first algorithm (A1) which only transfers complete messages to the application layer.

Figure V.9 : Patterns providing stream service Sending Entity Pattern

Sub-Network Connection

Receiving Entity Pattern Fragmentation

Numbering Flow Control RTT estimation

Retransmission Padding Retention Transfer DATA go-back-n on wtimer

Un-padding Resequensing

Coalesce Transfer CNTL Transfer Message/A1

V . 4 . 2 . X T P P r o v i d i n g a n I s o c h r o n o u s S t r e a m S e r v i c e

Isochronous Stream Service is also known as real time CBR service. It can be provided by XTP to transfer, for instance, an audio or video stream. XTP assumes that the underlying network is capable of providing certain quality-of- service guarantees for the bandwidth and error rate necessary to support the audio and video streams effectively.

Figure V.10 : Patterns providing isochronous stream service Sending Entity Pattern

Fragmentation Numbering Rate Control

Padding Transfer DATA

Receiving Entity Pattern Un-padding

Resequensing Coalesce Transfer Message/A2

Connection

Sub-Network

An isochronous stream requires in-sequence synchronized delivery of data at the receiver and a small fixed-sized maximum data unit. However, it is tolerant to losses. As introduced in section V.2.3., the rate control function has to be tuned correctly to provide a synchronized delivery of data. Furthermore, certain functions have to be removed from the protocol pattern providing the isochronous stream service, such as flow control and retransmission functions.

Duplicate units are removed by the resequencing function. The message transfer function associated with its second algorithm transfers messages to the application synchronously. If no message is available to deliver to the application (e.g., if it did not arrive in time or was discarded due to buffer overflow or corruption), several strategies may be implemented. If the isochronous stream transports a video stream then the previously received message may be passed to the application again. Although this strategy may slightly reduce the quality of the video, it is an acceptable loss recovery strategy as long as the picture remains

comprehensible [86]. If the isochronous stream transports an audio stream then the protocol may submit either nothing or white-noise.

Figure V.10 shows the patterns of two peer-entities providing an isochronous stream service.

V . 5 . C

O N C L U S I O N

We shown the usefulness of the Function Based Methodology to model a recent high-speed transfer protocol, XTP. The building of the model was almost straightforward when all the steps defined by the methodology are followed. The model is reconfigurable and several services can be provided such as those presented: stream and isochronous stream services.