The Suitability Of Transport Protocols For Response Time: [Essay Example], 2715 words GradesFixer
exit-popup-close

Haven't found the right essay?

Get an expert to write your essay!

exit-popup-print

Professional writers and researchers

exit-popup-quotes

Sources and citation are provided

exit-popup-clock

3 hour delivery

exit-popup-persone
close
This essay has been submitted by a student. This is not an example of the work written by professional essay writers.

The Suitability of Transport Protocols for Response Time

Download Print

Pssst… we can write an original essay just for you.

Any subject. Any type of essay.

We’ll even meet a 3-hour deadline.

Get your price

121 writers online

blank-ico
Download PDF

Our team is collaborating with an industry partner on development and optimization of the system called Universal Radio Gateway (URGW). This system provides a capability of integrating the radio stations of various proprietary analogue and digital radio systems like TETRA, TETRAPOL, etc. into a larger complex communication infrastructure. The rest of this infrastructure is mostly based on VoIP, mobile networks 3-4G and PSTN. The radio systems of this type are mostly used by army, police, firefighting and emergency forces. Among other things, the URGW system allows the operator-dispatcher to control the radio station remotely and use it as a kind of single line trunk from the generic VoIP-PSTN infrastructure to the proprietary radio network. The goal is to preserve as much radio system capabilities as possible and transform the services into the VoIP environment transparently. It is expected that the used radio station is granted some higher rights in the radio network (ie. radio group manager) but in all other ways behaves still just like regular end user radio station with no special access to the radio network management system. Thus the URGW accesses the services of the radio network mostly by emulating the living user control of the connected stations. Despite being a lot more complicated in its real form, the URGW system can be simplified into three basic modules for the purpose of this paper see Figure 1.

High level URGW systm architecture

A. Dispatchers Post (DP) Dispatchers post is a computer station where a living person is managing the communication process and facilitating the smooth transition from full-duplex PSTN/PLMN/VoIP environment to the half-duplex radio environment. Once the operator chooses the remote station from the list, the dispatcher post connects to the radio station using the radio station controller and starts utilizing it in the communication chain.

B. The Arbiter The arbiter is an automatic backend entity managing the lists of available radio stations, their actual states and advertised services. If a dispatcher wants to use particular station, he asks the arbiter and the access is granted if there is a match of demanded and offered services. Once the station is occupied it is removed from the list of available stations and other dispatchers are not able to access it. The station/dispatcher registration process as well as the connection setup is based on SIP protocol. Typically the arbiter is a module of bigger communication system like VoIP PBX exchange.

C. Radio Station Controler (RSC) Radio station controller is a device connected to the physical radio station by a proper interface. The interface is strongly dependent on actual station capabilities. In the most primitive case it may be only an analogue audio channel with a keying control just as if a living person was operating the textove polestation. More sophisticated stations would provide some digital interface mostly with some proprietary protocol. Once the Dispatcher and a station establish a control session, an URGW proprietary protocol is used for both control messages and audio channel. Optimization of this signaling transport over the IP network is the main aim of this paper.

All the system parts are connected to an IP network which in praxis is some kind of WAN connection. In present implementation of URGW a SIP protocol methods MESSAGE and INFO are used for encapsulating and transporting the peer to peer DP-RSC signaling. Standard SIP UDP transport is used. The actual setup is already used in several production deployments, but has shown some limitations when the used IP is of less quality or is overloaded. The biggest observed issue is faulty keying control. The keying command may be issued either manually by the dispatcher or remote VoIP party or in some cases even automatically by VoIP system detecting the end of speech (changing-over). This is where the actual full/half duplex adaptation takes place. The proper and quick transport of keying command to the radio station is crucial for end user voice communication comfort. Since the industry partner is redesigning the whole URGW now, we were given a task to investigate all possible transport protocol setups to give the definitive answer which one suits the best to this type of application.

Anyway the main goal is to let the system be able to measure (or guess) the Tx time properly. Using Tx system can indicate to the user when it is safe to start talking, so first words won`t be cut off. This indication is normally done by a short beep in audio channel. Figure 3 shows the acknowledged variant (E) for TCP transport. There are three transport protocols available in IP networks. UDP [1] is an unreliable connectionless datagram service. UDP must be used with some additional reliability assurance mechanism. The rest TCP [1] and SCTP [2] are both reliable connection oriented protocols. We believe the reader can guess the rest setup details just by the names. Of course the keying command is not the only one to be transferred in DS-RSC signaling but, as practical experience shows it is the only one having serious issues on lower IP network quality levels. The rest of commands are simply less real-time demanding.

For UDP, TCP and SCTP protocols we have used the INET Framework [4]. The simulation application is nearly the same as the real one. The only difference was that there were no threads in the simulation. We utilized the property of simulation engine, i.e. the time moves forward only when a new event occurs. There are no delays between layers communication and processing of all packets/messages is absolutely parallel and non-blocking. We have proved the correlation of results obtained by OMNET/INET and the live signaling transport in our previous paper. The application simulates one scenario for all transport setups. The user (client) pushes the keying button every (configurable) time period and the opposite site (server) is informed about this event. The two sites are connected via a simple network channel which has the defined one way delay and packet loss parameters. Message size can be set up as well so the bandwidth issues could be simulated as well. Figure shows the OMNET simulation print screen running in slow mode.

L4PING APPLICATION

The real Linux application was also created along with the simulation model to prove the real Linux transport protocols implementation behavior and compare it with results obtained with simulation. We internally named this application L4ping. At the application level, the user sends the requests at a defined frequency ( ie. one message is sent every 50ms). The user requests are stored in the buffer which is emptied by the chosen transport layer (TCP, UDP or SCTP). Every transport layer uses two threads, one for sending messages and one for receiving. The total effective (application to application) transport time is measured at the application layer by comparing timestamps stored as the actual message content. In real world there are however some complications that did not apply in simulation. The first one is precise timing. The simulation event takes no time unless it is explicitly programmed do so. In simulation it is no problem to process incoming and outgoing packet at the same time. To minimize the impact of the delay of real packet processing L4ping tries to work as parallel and non-blocking as possible. There are two threads at application level, the first one only sends and timestamps the notifications, the second one only receives and timestamps the replies and sends the acknowledge if ACK is turned on. At transport level there are also two threads, one for transmission and one for reception. For UDP there is also another thread used for precise timing computation when the application acknowledgement is required.

Simena NE2000 network emulator [6] was used to emulate similar setup in real network as the shown in the OMNET++ simulation. The emulator provided the controlled network parameters downgrading. To simplify the proper time measurement and eliminate the two machines internal time synchronization problem a single machine setup was used. In this setup the client and server application were both run on same machine using two Ethernet NICs. The packet routing was manipulated using iptables. Double ingress and egress (prerouting and postrouting) packet manipulation was done so the packets originally designed for the local interface were now sent to the physical network interface. These packets would have otherwise/normally been routed just internally by the kernel and did not even reach the network layer. This way a controlled network parameters downgrading could have taken place and simple internal machine clock timestamping was enough to measure the messages arrival times properly.

The only real information being transferred was the timestamps. The rest of 200 bytes was just dummy bits. Of course since the simulated computational power is virtually unlimited in simulation model, the actual amount of data being transferred had no effect on the results. 200 bytes was small enough so that the message length had also not any big effect on real measurement as well (neither when it comes to buffers processing or bandwidth limitations). To speed up the measurement a message was generated every 50ms for UDP and every 800ms for TCP (to lower the head of line blocking) and SCTP. The keying commands are normally issued in more than ones of seconds frequency so are not demanding in this respect at all. Occasionally some other signaling may need to be transferred in same channel as well, so a slightly higher message generating frequency was used. Only some time/message loss table sets are shown the for space saving. The complete dataset can be provided upon request.

A. Multiple UDP, no app ACK Setup: This is the simplest variant where some level of reliability is achieved just by sending the multiple identical messages at a same time. No ACK is used on application level. Sending multiple copies of same message is a bandwidth waste, but with respect to expected message frequency and size we do not consider this to be a problem. Simulation vs real app match: Simulation and the real measurement results have shown nearly 100% match. Results: Since the delivery process is just one time pass, the delivery times follow the channel delay precisely (only the times for the messages that were really delivered can be taken into account of course). Time result table does not even need to be shown. With more redundancy the message loss gets better. Using 5 times message multiplication the loss was finally low enough so this setup could be acceptable for our purposes. (less than 1% for PER 0,4 and less than 3% for PER 0,5). There is no application ACK so the actual Tx would have to be guessed by measuring the RTT periodically sideway if this setup is chosen.

B. UDP with application ACK Setup: In this setup a SIP-like exponential back-off for application level acknowledgment was adopted [7]. This setup was mainly chosen to emulate the actual URGW implementation and investigate if the actual application can be improved just by fine-tuning the already used SIP stack. In our measurements the timers T1/TE was set to 50ms (instead of SIPs default 500) so the retransmission process was more aggressive.

C. Multiple UDP with application ACK Setup: This is the combination of A and B variants. Both original and ACK message is multiplied x times in order to increase the redundancy. Simulation vs real app match: Simulation and the real measurement results have shown excellent match. Results: This setup showed a slightly better average delivery times since the redundancy have clearly eliminated a lot of retransmissions in compare to variant B. The measured average message loss was nice, under 1% even for PER 0,5 for 2x redundancy and zero for 3x and more redundancy.

D. TCP with no application ACK Setup: Simple TCP transport variant. TCP is known for the so called head of line blocking problem when it comes to transport of individual independent messages (ie. signaling) [8]. Despite this, we wanted to give TCP a chance, since in our application we do not expect any high frequency of messages. (the 800ms message generation frequency was used ). Simulation vs real app match: A simulation model has shown comparable results than the real application. As expected, the blocking shows slightly more often in the real world due to real TCP stack servicing is more demanding than the ideal one in the simulation model. On the other side in real application the already blocked stream still works a bit better showing lower total average times. Results: Despite rather low message generation speed the head of line blocking has clearly shown up and since the problem is cumulative (one delayed message slows all the subsequent and so on). The occurrence of the blocking is not 100% correlated with the rising PER/LOSS. Even for the higher PER/loss combination the blocking may or may not occur, but once it occurs, this TCP connection is “lost” for the rest of measurement. It does not make sense to measure the actual loss since TCP allows no loss and all the messages will be delivered at the end, but the points where the average measured delivery time is higher than the 10 times the actual line delay can be considered unsatisfactory. This setup is clearly unusable for our application.

E. TCP with application ACK Setup: Similar as D variant, but with application ACK enabled. Both request and ACK messages use the same TCP connection transport. Application ACK might still make sense even for the TCP transport since it can help the application measure the RTT and guess the Tx by it. Simulation vs real app match: The simulation has shown better results than real measurement once again. The reasons and are the same as in D variant. Results: The head of line blocking persists and the impact is even amplified, because the blocking could occur on both request and ACK ways. This setup is clearly unusable for our application.

F. SCTP, no application ACK Setup: SCTP is a protocol specially designed for signaling transport [9], so this setup was promising. SCTP socket was initialized in a message mode with unordered mode enabled to eliminate the head of line blocking. For the real application the standard SCTP implementation available in Linux was used (libsctp-dev, lksctp-tools, libsctp1, all version 1.0.16). There may be more complete commercial implementations of SCTP available but the goal was to test the open source one. Simulation vs real app match: The simulation has shown similar results when everything was working fine, which unfortunately was not the often case. Results: The INET implementation of SCTP transport seems to be buggy. With PER/delay combinations getting worse some simulation runs went kind of “mad” showing similar results as if there was head of line blocking. The head of line blocking is virtually impossible if an unordered mode is enabled, but so is 17s the average delivery time on 250ms delay line + 0,5 PER. So it seems that the INET SCTP stack was not working consistently at worse delay/loss conditions. On the other side real application SCTP usage had its own different problems. In some cases the SCTP association had serious problems to get even established, staying hung up in waiting for COOKIE ACK state. We tried to overcome this problem equipping the application with a watch thread which simply restarts the try if this hang-up occurs. But even killing the application did not succeed to free the previously occupied SCTP socket properly every time. The results obtained in the cases when SCTP transport was working fine seemed promising, but for obvious reasons this setup can`t be recommended for production use yet.

G. SCTP with application ACK Just like TCP, SCTP is a reliable transport protocol but still the application ACK may make sense due to RTT measurement for Tx guessing. Nevertheless same conclusions apply for this case as stated in the F variant. The SCTP stacks in both simulation and real application did not perform consistently enough. CONCLUSION All the available transport protocols setups for the given application signaling transport have been tested both in OMNET++ simulation environment and real Linux application. The best results were obtained with variant C which combines the application ACK with exponential back-off and multiple message redundancy. Unfortunately we did not have the access to any commercially available SCTP stack implementation to test it.

Remember: This is just a sample from a fellow student.

Your time is important. Let us write you an essay from scratch

100% plagiarism free

Sources and citations are provided

Find Free Essays

We provide you with original essay samples, perfect formatting and styling

Cite this Essay

To export a reference to this article please select a referencing style below:

GradesFixer. (2019). The Suitability Of Transport Protocols For Response Time. Retrived from https://gradesfixer.com/free-essay-examples/the-suitability-of-transport-protocols-for-response-time/
GradesFixer. "The Suitability Of Transport Protocols For Response Time." GradesFixer, 27 Aug. 2019, https://gradesfixer.com/free-essay-examples/the-suitability-of-transport-protocols-for-response-time/
GradesFixer, 2019. The Suitability Of Transport Protocols For Response Time. [online] Available at: <https://gradesfixer.com/free-essay-examples/the-suitability-of-transport-protocols-for-response-time/> [Accessed 18 September 2020].
GradesFixer. The Suitability Of Transport Protocols For Response Time [Internet]. GradesFixer; 2019 [cited 2019 August 27]. Available from: https://gradesfixer.com/free-essay-examples/the-suitability-of-transport-protocols-for-response-time/
copy to clipboard
close

Sorry, copying is not allowed on our website. If you’d like this or any other sample, we’ll happily email it to you.

    By clicking “Send”, you agree to our Terms of service and Privacy statement. We will occasionally send you account related emails.

    close

    Attention! this essay is not unique. You can get 100% plagiarism FREE essay in 30sec

    Recieve 100% plagiarism-Free paper just for 4.99$ on email
    get unique paper
    *Public papers are open and may contain not unique content
    download public sample
    close

    Sorry, we cannot unicalize this essay. You can order Unique paper and our professionals Rewrite it for you

    close

    Thanks!

    Your essay sample has been sent.

    Want us to write one just for you? We can custom edit this essay into an original, 100% plagiarism free essay.

    thanks-icon Order now
    boy

    Hi there!

    Are you interested in getting a customized paper?

    Check it out!
    Having trouble finding the perfect essay? We’ve got you covered. Hire a writer

    GradesFixer.com uses cookies. By continuing we’ll assume you board with our cookie policy.