This document is the second annual progress report of the HIPPARCH project. HIPPARCH (HIgh Performance Protocol ARCHitecture) is the EC ESPRIT IT Long Term Research 21926. It began August 1996.

The project partners are:

• INRIA - Institut National de Recherche en Informatique et en Automatique - project co-ordinator,
• DE - Dassault Electronique - industrial partner.
• UU - Uppsala University.
• SICS - Swedish Institute of Computer Science.
• UCL - University College London.
• UTS - University of Technology, Sydney.

Two major European companies, British Telecom (BT) and Ericsson Radio AB (ERA) are participating in the steering committee of the project.

HIPPARCH aims at investigating novel protocol architectures for high performance communication based on the Application Level Framing (ALF) and Integrated Layer Processing (ILP) concepts.

This project extends the result of a previous HIPPACH EC-AUS activity, where the ALF based design has been validated, to the broadest possible range of information services and applications. The goal of the project is to study the benefit of the ALF and ILP principles for the design of communication systems supporting multicast, mobility and real-time media.

The project results are:

• a protocol compiler that will allow to validate the use of formal description techniques to design ALF based communication architecture,
• specific control algorithms for unicast, multicast and " network conscious applications " mixing real-time and non real-time data transfers,
• software environments allowing new generation protocol implementations,
• demonstration and evaluation platforms allowing the evaluation of the accuracy of the proposed communication architecture and of the associated software tools,
• take-up of the results by both standardisation groups and industry, to allow competitive advantage in producing efficient communication software.

All technical results were provided on time, i.e. after 2 years of project. The project partners therefore had to request a project extension in order to complete the following tasks:

• Organize an industrial event
• Integrate UTS results. UTS joined the project as an official partner after one year.
• Clean prototype softwares developed during the project in oreder to make HIPPARCH results available on the world wide web.

The second year objectives are recapitulated in the following list of final deliverables. At the time of the review, all contracted work has been done. Final deliverables are available on the HIPPARCH project web site, http://www.docs.uu.se/hipparch/.

HIPPARCH partners have participated and contributed extensively to the IETF working groups. INRIA, UCL, DE, and SICS participated in all meetings. INRIA, UCL, and SICS are authors of RFCs and Internet Drafts. There are three IETF meetings per year. Second year’s meetings were in Washington DC in December 97, Los Angeles in April 98, and Chicago in August 98. UCL, INRIA and DE are also active participants in IRTF’s Reliable Multicast Research Group. RMRG had 3 meetings this year; 2 of them were hosted by HIPPARCH partners (INRIA in September 97 and UCL in July 98). Jon Crowcroft is a member of IAB, and of the IRTF’s End to End research group, as well as a co-chair of two IETF Working Groups.

HIPPARCH partners are also Program Committee members in many International conferences and workshop such as ACM SIGCOMM, IEEE INFOCOM, IEEE GLOBECOM, IFIP HPN, IFIP IWQoS, etc.

Christophe Diot and Jon Crowcroft participate to the COST 237 project (Multimedia Tele-services) and meetings, and their respective organisations are members of Cabernet. There were two meetings (including a workshop) during HIPPARCH project second year : Lisbon (workshop chaired by Christophe Diot and meeting) in December 1997 and Berlin (together with ECMAST conference) in May 1998. Diot and Crowcroft are also the founder of a new COST project dedicated to group communication infrastucture (COST 264 "Costbone").

Travel related to workshop and conference participation is detailed in the next section.

There have been several examples of staff mobility within the HIPPARCH project. Long-term exchanges were mostly between UTS (Australia). Short-term visits are not detailed here; but they where required to co-ordinate the technical development in the project (UU-INRIA, UCL-INRIA, DE-UCL, INRIA-DE collaboration will be described in the technical achievement section).

• Lorenzo Vicisano (UCL) attended INRIA to help with port/integration work with protocol from manual implementation to automatic specification – involved re-writes of some protocol modules in Java.
• Bjorn Landfeldt (UTS) attended INRIA to work on the integration of the IP integrated services in his QoS architecture.
• Per Gunningberg
• Bengt Ahlgren
• Aruna Seneviratne

It should be noticed that there are also frequent meetings between project participants in conferences, workshops, and IETF meetings. The project members have prioritised the visibility of the project over and above the internal exchanges. Project scientific managers meet at least once per month in scientific events. Note that the project has also made extensive use of multimedia real-time conferencing for virtual meetings.

Research guests and visit outside the project will be described later in this report.

The following workshops have been organized by the HIPPARCH project members :

• ACM SIGCOMM ’97 in Cannes, France. September 14-18, 1997. SIGCOMM is the most prestigious and selective conference in the area of networking and Internet protocols. This year was a record with 400 participants, 250 papers submitted (of which 24 were accepted!).
• COST237 worshop in Lisbon (Portugal). December 15-18, 1997.

Mats Björkman of Uppsala University and Stephen Pink of SICS were program chair of the Global Internet conference, of Globecomm, Phoenix, Arizona, November, 1997.

The JSAC special issue on architectures for the 21^st century was published in April 1998 (this special issue was edited by HIPPARCH partners). The HIPPARCH project was also editor of a special issue of Computer Networks and ISDN Systems (CN&IS), in which the best paper of the June 98 HIPPARCH workshop were published. Jon Crowcroft coordinated this effort from UCL with the publisher/editor.

To conclude, here is a list of journals in which HIPPARCH members have published this year : IEEE Networks, IEEE JSAC, CN&IS.

It should be noticed that, among these publications, a large proportion involves two or more HIPPARCH project members.

Finally, an DE is preparing HIPPARCH participation to an industrial event. Details about HIPPARCH contribution will be given section 6.

27 October 1997. Project meeting at UCL to analyse the consequence of the review and schedule precisely the work to be done during the second year.

27-28 January 1998. Project technical meeting at INRIA in Sophia-Antipolis, France.

20 April 1998. Project management meeting at DE in Paris, France. Preparation of the final review agenda and demonstrations.

15-17 June 1998. HIPPARCH Workshop and technical meeting in London (UCL). Preparation of the final review.

20 August 1998. Last coordination meeting before the final review.

The HIPPARCH project has attracted the interest from various European and international companies :

All deliverable have been published (or are being published) in international conferences, workshops, and journals.

• Task 1.1 allowed INRIA to complete the HIPPARCH EC-AUS activity compiler with data processing and to evaluate it with various applications. This task helped in defining the properties and the structure of the final ALFred compiler. Also during this task, the project partners decided to change the data description language and the implementation language to use Java instead of C. This choice may reduce performance, but make automated implementations portable and independent of the Operating System.
• Task 3.1: It consists of a report on the findings and a set of appendices of published papers. The purpose with the architecture is to provide predictable service to applications and efficient usage of resources. The management of the CPU and the network interface have been studied. A combination of a rate based scheduler for the CPU and provisions for fair sharing at overload situations ensures predictability and efficiency. The network interface couples DMA scheduling with traffic shaping which also ensures both predictability and efficiency. Both subarchitectures have been implemented and their effectiveness has been demonstrated with measurements.
• Task 3.2: This task has resulted in deliverable SICS-1 in the form of a report and software. The software is an API in Java which provides functionality needed by network conscious applications for probing the current state of the network to a particular destination. The results deviate somewhat to what we anticipated in the project programme, but is the consequence of the research results from work package 2 on QoS models for network conscious applications.
• Task 3.3:
• Task 4.1 UCL is responsible for the application set specification – this was largely completed in year 1, but the final deliverable is due at T0+18. This is being ratified at the project meeting at INRIA in January 1998.
• Task 4.2 This is the HTTPng specification. As part of the visit to INRIA, Dr Vicisano is helping with the formal specification so that the manual implementation of the RLC protocol (BMART/RMDP, as per the INFOCOM 98 paper) and the Java specification that surrounds it, can be written up.
• Task 4.3 D.E. are principally responsible for the demonstration. L.Vicisano has worked closely from the late 97 meeting until spring 1998 in coordinating the protocol (manual and automatic versions) with Dassault.

The collaboration aspect has been important in the second year of the project with the integration of each partner’s results and demonstration of the HIPPARCH architecture.

INRIA has participated to all the IETF meetings (3 per year), and to the main scientific event in the research community (INFOCOM, SIGCOMM, GLOBECOMM, and various workshops in the US and in Europe).

All the articles were presented by members of the rodeo project in the corresponding conferences and received good feedback from the reviewers, and good scientific evaluation.

Christophe Diot, for INRIA was also co-chair of the HIPPARCH workshop organized at UCL, and chair of the COST 237 workshop in Lisbon (December 1997).

Despite the end of the project, INRIA will pursue activities started task 1.1 and 3.1.

• Task 1.1: The protocol compiler is being used with software radio application for NORTEL.
• Task 2.2: A new approach to QoS management is being implemented by a PhD student at UTS.

• Task 3.1: INRIA has been a major contributor in the area of differentiated services on the Internet and intends to continue the related activities until an Internet standard is defined.

INRIA has 3 final deliverables that have been completed on time. More details on these deliverables and on the results developed in these deliverables is available section 2.6.

Human resource per task :

Task 1.1 : 6 mm (INRIA local resource : 12 mm)

Task 3.1 : 4 mm (INRIA local resource : 18 mm)

Task 3.3 : 6 mm (INRIA local resource : 6 mm)

Task 4.3 : 6 mm (INRIA local resource : 6 mm)

 Total for the first year : 22 mm (INRIA local resource : 42 mm)

The following people have participated to the project :

Diot task 1.1 ( mm), task 3.1 ( mm), task 4.3 ( mm)

Kaplan task 1.1 ( mm), task 3.3 ( mm), task 4.3 ( mm)

Turletti task 1.1 ( mm), task 3.3 ( mm), task 4.3 ( mm)

Bolot task 3.1 ( mm)

Levine task 3.1 ( mm)

The tasks described in the PP have been completed with minimal changes. Detailed men-month allocation is described here before.

There is no change in the PP that need justification, or that made that human resource had to be changed.

The extension required (with no funding) allowed INRIA to prepare a public version of ALFred, the protocol compiler, and to enhanced it with more communication libraries.

During this second year of HIPPARCH, INRIA has been involved in the following tasks:

• Design of the ALFred protocol compiler (task 1.1). ALFred now provides a full environment for the design of formal application specification and for the automated generation of implementation. In addition to what is written in the Project program, ALFred has the following features:

7. Publications

F. Gagnon and C. Diot. "Impact of Out-of-Sequence Processing on Data Transmission Performance". INRIA Research Report RR-3216. INRIA Sophia Antipolis (France). July 1997.

V. Roca, T. Braun, C. Diot. "Demultiplexed Communication Architecture for Streams". IEEE Networks journal. July 1997.

I. Chrisment, D. Kaplan, and C. Diot . "An ALF Communication Architecture: Design and Automated Implementation". To be published in the IEEE JSAC special issue on Architectures for the 21^st century. 1998.

M. May, J. C. Bolot, C. Diot, and A. Jean-Marie. "1-bit schemes for Service discrimination in the Internet: analysis and evaluation". INRIA Research Report 3238. INRIA Sophia Antipolis (France). August 1997.

M. Fuchs, C. Diot, T. Turletti, M. Hoffman. "A Framework for Reliable Multicast in the Internet". INRIA Research Report RR-3363. INRIA Sophia Antipolis (France). 117pp. February 1998.

B. Landfeldt, A. Seneviratne, and C. Diot. "User Services Assistant: An End-to-End Reactive QoS Architecture". IFIP/IEEE IWQOS '98 proceedings. Napa Valley. May 1998.

M. Fuchs, C. Diot, T. Turletti, M. Hoffman. "A Naming Approach for ALF Design". HIPPARCH workshop proceedings. London. June 1998.

J. Crowcroft, L.Vicisano, Z. Wang, A. Ghosh, M. Fuchs, C. Diot and T. Turletti. "RMFP: A Reliable Multicast Framing Protocol". Internet-Draft. March 1998.

Lorenzo Vicisano spent a 2-weeks period visiting INRIA, during which he helped in the integration of RLC/RMDP software modules into the Alfred compiler. He was also involved in the specification of the software module interfaces and functionality needed for the process of automatic generation.

 UCL has participated in all the IETF meetings (3 per year), and has a presence at the main scientific event in the research community (INFOCOM, SIGCOMM, GLOBECOMM, and various workshops in the US and in Europe).

Jon Crowcroft, for UCL was also co-chair and organiser of the HIPPARCH workshop organized at UCL.

Three of UCL’s pieces of work relating to the project, namely the TCP multiplier work by Philipe Oechslin, the RLC work by Lorenzo Vicisano, and the Self-Organising Transcoder work by a PhD student of Jon Crowcroft’s, Isidor Kouvelas, have been reported in papers submitted for publication at ACM CCR, IEEE INFOCOM, and the ACM Multimedia Conference respectively. All three pieces of work involved both protocol implementation, and simulation using the Berkeley VINT projects network simulator, ns. The simulation modules for the multcp, rlc and s.o.t., have been donated back to the Vint project with documentation so that they may be disseminated to the wider community.

HIPPARCH project activitiees are also continuing beyon the framework of the project:

• Task 4.1 : The application set specification is also being used as a driver for work in a DARPA funded project wit h SAIC, MIT and ISI. Also, network pricing work between BT and UCL is using the profiles created by this work.
• Task 4.2 : UCL is pursuing standardisation of the HTTPng framework, although it is not clear if this is W3C or IETF work.

UCL has 2 final deliverables that have been completed on time. . More details on these deliverables and on the results developed in these deliverables is available section 3.6.

Human resource per task :

Task 4.1 : 3 mm (UCL local resource : 3 mm)

Task 4.2 : 8 mm (UCL local resource : 9 mm)

Task 4.3 : 7 mm (UCL local resource : 2 mm)

Total for the first year : 18 mm (UCL local resource : 15 mm)

The following people have participated to the project :

Vicisano task 4.1 ( mm) , 4.2 ( mm), 4.3 ( mm)

Wang task 4.1 ( mm)

Oechslin task 4.2 ( mm)

White task 4.3 ( mm)

Davey task 4.3 ( mm)

There is no change in the PP beyond year 1 already reported. Resources are as per planning.

UCL second year activity has consisted in the HTTPng framework specification refinement and implementation, and in the implementation and performance tuning of the multicast transport modules: RLC and RMDP. UCL has also ported both RLC and RMDP to Java in order to facilitate the performance comparison with the automated implementation of the protocols. The availability of Java code also allows a better integration with software modules produced by the other partners. UCL has finally helped in the preliminary stages of the automated implementation by specifying protocol functionality and software module interfaces.

During this second year of HIPPARCH, UU has been involved in the following tasks:

• Application-to-application resource management (task 3.1)
• Continued the work on adaptive resources management, ie CPU scheduler and bus arbitration.
• Implemented novel resource management schemes and protocols on the MIT Exokernel architecture. Comparison with Unix schemes.
• The work on co-scheduling of DMA transfer and traffic shaping has been generalized for variable packet sizes. A journal version of the result has been produced.
• End-to-end compression that adapts computing resources at the end systems and available bandwidth. This work generalizes work done in the first year and aim at a journal publications. More quantative results has been obtained, as was requested at the first year review.
• An experimental API supporting protocol modules built with ALFred (task 3.2)
• Participated with SICS on the design of an interface to the Networking probing software.
• Integration with ALFred (task 3.3)
• Participated in the design, implementation, experimentation and integration of the network resource monotoring and API interface to ALFred
• Algorithms for network conscious applications (task 2.2)

Efforts have been carried out this second year in order to publish this work in a journal.

• Automated Generation of the demonstration application (task 4.3)

• UU-2: Report on experiments with a host resource management architecture.

Total for the second year : 12 mm (UU local resource : 6 mm)

The following people have participated to the project :

Gunningberg task 3.1 (4 mm), task 3.3 ( 1 mm), Mgt (1 mm)

Björkman task 3.1 ( 1 mm), task 3.3 ( 2 mm)

Melander task 3.1 ( 1 mm), task 4.3 (2 mm)

Knutsson task 3.1( 6 mm)

Resource reservation and control in Unix for applications is cumbersome. We had to modify the kernel, the API:s and the drivers for our first year experiments. The Exokernel of MIT offers an attractive alternative approach. The low level abstractions are exported and user accessable library OS are used. These libraries can be modified for communications software without compromising secure multiplexing of resources. We have done experiments with protocol written in the language Erlang and compared the results with a traditional Unix implementation.

(Note: this need some thoughts and adjustments to match the above)

[SICS-1] Bengt Ahlgren and Mats Björkman, "Network probing for network conscious applications..."

Human resources per task : First half, year 2:

Total for the first half of year2 : 4 mm (DE local resource : 12 mm)

The following people have participated to the project :

In the QoS management architecture being developed under WP2, the communication subsystem may be chosen at run time, depending on the application and the operating environment characteristics. This implementation enables the dynamic configuration of protocols using a library of protocol functions.

The basic protocol structure consists of three main elements - the shell, the control channel and the data channel. This basic structure is illustrated in Figure 1.

The shell forms the user interface to the protocol stack and allows the users to open, close and reconfigure data channels as required. This is equivalent to the socket layer of the BSD TCP implementation.

The control channel is responsible for the setting up, tearing down and reconfiguration of data channels. No user data can be sent a long the control channel. There is one control channel for each shell. The control channel remains open until all data channels and the shell are closed.

The data channel is used for the transfer of all user data. The data channel supports a variety of protocol mechanisms which fall into four main protocol function groups - sequencing, error control and recovery, flow control and application layer framing. Further details on the different mechanisms and configurations supported are given in section 0. Each terminal can support multiple data channels each configured with its own protocol.

Figure 1, shows the different threads that would be running within the protocol. The main user thread is used for the shell user interface calls. Three threads each are necessary for the control channel and every data channel - one for the input process, output process and a timer process.

The Table 1 above shows the different functionality that the protocol currently supports and the mechanisms that are being used to support each functionality.

A variety of different configurations are possible with the above number of mechanisms - the only restrictions are that the error control function's Go-back-n and Selective Repeat and the flow control function credit control require sequencing and hence can not be used with no sequencing.

The functionality defined in this prototype of protocol stack is not exhaustive but is designed to allow experimentation with various combinations of protocol functionality and to study how they will interact. Thus there is still a lot of different groups of functionality that can be added to allow for a greater range of application specific protocols to be defined.

Integrated Layer Processing (ILP) was not used in the implementation as initial experiments and recent research results showed that the benefits from ILP was not deterministic, and could result in loss of performance for complex functions. Further more given that the implementation was designed to be a runtime protocol, problems

arise when attempting to introduce compile time implementation optimisations like ILP.

Sequencing is used for checking the order in which packets are accepted when the arrive at the machine.

Mechanisms currently used for supporting sequencing :

Error control mechanisms are used for recovering from errors. The errors are normally detected by the sequence mechanism or by a timeout occurring.

Error control mechanisms currently defined:

Flow control is used to prevent the sender from transmitter more data than the receiver can handle which would normally result in data being lost. Flow control can also be extended to include congestion control which attempts to prevent the network from being flooded with packets.

Mechanisms for supporting Flow Control -

The following is a list of possible mechanisms that could be added to the implementation to increase its functionality. Once again this list is not intended to be exhaustive but to illustrate how the implementation’s functionality can be extended to support a greater range of protocol configurations.

Basic protocol operations like setup, disconnect and reconfiguration of data channels are conducted through the control channel. Figure 3, Figure 4 and Figure 5 show the exchanges for the different operations.

For opening a channel, the initiating entity sends an open request which contains details like the UDP port and protocol for the new channel. The second replies with its UDP port number and confirms the protocol to be used. The second entity then waits till it receives the first data packet before it starts sending data.

For closing the initiating entity sends a request packet and waits till it gets a reply before closing the channel.

Protocol configuration exchanges are similar, with the difference being when the protocol request is sent - the data channel moves into a protocol wait state where it waits for a reply during this time no processing takes place within the data channel. When the peer entity receives the request it moves into the protocol wait state - changes its protocols and then returns to the open state after sending the reply. Then initiating entity switches the protocol mechanisms when it receives the wait state and then moves into the open state.

The dynamic protocol was implemented on a Linux platform as an user level implementation. As explained earlier, it is a user level protocol because it was intended to interact with the application, and was designed to allow the user to create their own protocol functionality and this was easier to achieve if the protocol was outside the kernel. The prototype was built on top of the kernel level protocol UDP. Implementing the protocol over UDP was chosen for a number of reasons. By implementing it on top of UDP we had a way of demultiplexing the control and data channels by using different UDP ports. This would have been more difficult it attempted over raw IP sockets. Secondly UDP does not provide any functionality other than a checksum which is mandatory on the Linux implementation. This allowed us to design a protocol which provides all functionality with one exception -- it assumes that packets arriving from the underlying network are correct and does not carry out any detection for bit errors as it is assumed that this would be found by UDP’s checksum. Thirdly, it was considered more reasonable to use a standard socket interface to access the network, rather that access the underlying device drivers directly as this would have required super-user access.

To be able efficiently support a protocol stack that supports multiple channels, a control channel and adaptivity it was necessary to support multiple threads of execution. For this reason, a pthread package that would run on top of linux was

necessary. Proven's pthread package from MIT provides an user level POSIX compatible thread library. This package was used to provided multithread support. The Proven pthread package was the only user level package available and produced better results when switching compared to INRIA’s kernel pthread package. The only weakness in using this package was that all the pthreads run over a single process and hence the execution time of the process has to be shared with all the pthreads.

C was the language chosen to implement the protocol due to difficulties using C++ with the pthread library. C++ was originally envisioned as being more suitable protocol due to its object oriented programming methodology.

Currently it has been implemented as a library which includes the current functionality as part of the library. It will be preferable for future implementations to separate the functionality mechanisms from the main protocol engine. The mechanisms should be dynamically linked into the protocol as required. Furthermore by separating the functionality mechanisms form the main engine, it will allow for new mechanisms to be downloaded into the engine thus reducing the need for an end system to contain all the necessary mechanisms. The costs of dynamically linking functionality is given in [Ric95].

The current size of the library including functionality is 55 Kbytes. An individual mechanism is expected to be around 1-3 Kbyte in size which gives an encouraging view for the possibility downloading mechanisms. Current applications based on implementation are large and this is mainly due to the pthreads library which is 1.8Mbytes.

As has been mentioned, the implementation is a dynamically adaptive protocol stack, i.e. it is has the ability to change functionality during the lifetime of a connection. As shown above it supports four groups of functionality - sequencing, error control, flow control and application layer framing. Each of these functionality groups consists of a number of different mechanisms which can be used to instantiate the appropriate functionality group. Each mechanism can be considered an object consisting a number of procedures. The implementation calls these procedures from within its main processing loop. The various breakdowns for each of the protocol functions are shown in Figure 6.

The follow sections provide an outline of the services provided by each method in each of the different functions.

Sequencing function consists of a number of methods as shown in Figure 6.

Methods for Error control mechanism:

Methods for flow control functions

Methods for application layer framing functions :

All the threads are active while the connection is alive. The threads block while dynamic protocol changes take place as if they were frozen. The configuration of the new protocol is done through the control channel.

Table 2 shows some initial results for different protocol configurations. The performance varies depending on the protocol mechanisms used.

The best results are achieved for the protocol with no functionality at all. Given that the protocol has not been optimized at all this is understandable. Rate control simply restricts the number of packets that can be sent in an interval. The number of packets is adjustable. Rate control with go-back-n and selective repeats will provide poor performance similar to using no flow control. The reason for this is that rate control does not increase the rate that acknowledgments are sent and hence this is done as per the ARQ schemes which use delay acknowledgments. The delay for the acknowledgments means that new packets can not be sent and hence poor performance. When using the credit flow control scheme when the credits start to get low - it forces acknowledgments to be sent hence keeping the performance high.

Reconfiguration of the protocol during runtime takes approximately 5ms of which about 1ms is roundtrip time. Such reconfiguration times are reasonable for a mobile environment where experiments have shown that handoff times for Mobile IP can take

around 3 seconds [Cac94].

Comparisons with the performance of TCP and UDP in the same environment show that the user level protocol provides similar levels in performance as shown in Table 3.

The results show that user level application configurable protocols are viable and can provide high performance. In addition the implementation has shown that this can be achieved in a modular fashion.

Currently, it does not handle a number of problems relating to the specification and selection phases of the generic automated communication model. Work has to be carried out on how the user can specify their requirements to the user level protocol. The protocol must be able to decide depending on the environment what protocol functionality to be used and the appropriate mechanisms to be used.

At the moment, the only supports four classes of functionality, but there is no reason that this functionality cannot be extended to support more functionality groups. In particular presentation layer functionality can be added. This would be relevant to mobile systems where the bandwidth can be limited. The same applies to mechanisms which can be added to suit various application requirements.

Protocol configurations are currently decided by the users. One area of importance, involves deciding if a protocol is viable. For example, the has to be a mechanism for preventing an user from using sequencing and no error recovery as if a packet is lost it, the connection will come to a halt as the connection will never able to get back in the correct sequence.

In addition, it is unreasonable to assume that users will be able to decide what protocol functionality to use for their given application and their current environment, therefore it is necessary to build this intelligence into the protocol or within a larger framework. Particularly in a mobile environment, where network environment changes can require changes in protocol configuration it is unreasonable to expect the user to decide the correct functionality rather the functionality should be decided

based on a set of application requirements specified by the application designer and the underlying network environment.