For our performance analysis, we examine the basic setup scenarios with respect to parameter One-way delay. As the definition describes that there are two kinds of transmission protocols as default MPTCP and MPTCP- MS. First, default MPTCP where all the packets from different applications are multiplexed and scheduled over multiple links. And the second one,
proposed algorithm, takes specified paths for packet transmission (in our case two paths ppp0 and ppp1) benefiting the QoS parameter (OWD). The same experiment has been also observed in the TCP technique, which was only undertaken for the reference purpose. This is because it uses a single packet transmitting connection link with the lowest metric value. This technique is solely dependent upon the single connection link (ppp0) and can have effect on the QoS parameters if the different links is used. Since, this may not be a reliable source for quality assessment, this finding will not be used for the comparison purpose.
From our observations, in the case of experiments using packet size 1024 bytes by two applications one with 2 pkts/s and another with 5 pkts/s; as expected TCP´s performance was the worst with more than double OWD- normalize figure than the other two. This is may be because of TCP uses higher delay path for transmission. The MPTCP-MS performance was the best in every set of results with around 30% less then the default MPTCP. This is due to the less reordering of the packets coming from different links. Even after reducing the size of packets (i.e. 500 bytes), same kinds of res- ults were observed. But there is comparatively same distribution of OWD- normalize value in all the cases of 2 pkts/s with a lower median value of MPTCP-MS. Where as, in 5 pkts/s, a significant difference is observed. Another variation of transmission observation with two applications one with 10 pkts/s and other with 25 pkts/s, For 10 pkts/s, in the case of 1024 bytes packet size, the performance shown by the default MPTCP is quite similar to that of TCP. In theoretical approach, the default MPTCP should have shown better performance than that of TCP but due to some con- straints the result seems to be affected. Even in such constraints, the per- formance shown by the MPTCP-MS is remarkably good with less than half of the OWD normalize value. In the second test with 25 pkts/s with same packet size, the exact difference can be seen. TCP´s OWDnormalize value is largely distributed. Default MPTCP shows a little better performance than that of TCP and even though MPTCP-MS shows better performance value but still is more that of the previous one (i.e. 10 pkts /s). With these findings, we can suggest that MPTCP-MS performs better with less trans- mission rate. Similar results were observed while decreasing the packet size with similar transmission rates. The performance values for all the transmission protocols seems to be identical as of the 1024 bytes and 500 bytes of packet size used by both applications in 10 pkts /s and 25 pkts/s
simultaneously.
As to observe or replicate different behaviors in completely different set of transmission rate, we use 2pkts/s for one application and completely larger rate i.e. 25 pkts/s in another application. Commonly, as obvious 2 pkts/s in both cases OWDnormalize is minimally distributed and median value is lower than the 25 pkts/s. For both transmission rates, OWDnormalized is more distributed in 500 bytes packet size and others case (i.e. 1024 bytes packet size) are similar to each other. The medians of OWDnormailze value comparatively are more in 500 bytes of packet size.
In all above observations, some delay values are obviously very high that can be considered as outliers and shown in all boxplots. All our exper- iments show that in the scenarios used, the customized MPTCP strategy to create a selected paths among the available interfaces performs signi- ficantly better than the default MPTCP and normal TCP communication techniques.
Chapter 5
Discussion and Future Work
5.1
Discussion
This particular section of the report is focused on providing a general sum- mary regarding the procedures and protocols followed during the thesis along with the practical implementation of the project, the issues faced dur- ing the period of the project including the implementation phase and last but not the least, the outcome and the further possibilities regarding the future usage of this project as a base line for other projects as well.
TCP has been an industry standard in the packet transmission technology especially within the realm of World Wide Web and Internet, primarily fo- cusing on the reliable transmission of packets of data. With the TCP techno- logy as a foundation, MPTCP has been an ongoing development towards the optimum usage of multiple paths and resources to provide a better transmission service utilizing the concept of sub-flows.
Along with the increase in access devices with multiple network interfaces, the availability of these resources and the maximum and simultaneous us- age of this multiple network interface technology in order to increase effi- ciency for data transaction and transmission, this field of research is both exciting and demanding. With this particular scope at hand, the project has been focused on the selective transmission of data through multiple inter- faces as per the requirement of the user and the size of data. TCP has been an industry standard for the general transmission of data where a single connection is established between the source and destination points. With MPTCP there lies an option of using multiple paths using multiple inter-
faces for varied connection purposes between end points. MPTCP with se- lected interface (MPTCP-MS) was the proposed technology for this project, which enables the functionality of MPTCP; additionally support the selec- tion of specific path during transmission of data. It is possible by modifying the kernel of NorNet edge node to control over which path we want to send packets based on packetID.
In the initial stage of the thesis, the focus was particularly in developing a Telemedicine System prototype including the user interactive interface along with the data transmission aspect as well. However, adhering to the suggestions provided during discussions with faculty members regarding the project; the project and thesis has now been directed towards the com- munication and transmission factor as the premium agenda. With this said, it has been exciting and challenging to venture into this territory where TCP and MPTCP has been the technological basis of the project where the technology has been utilized with the assistive support of NorNet edge node for practical implementation of the technology using multiple mobile broadband networks provided by Netcom and Telenor. One of the major is- sues that was faced during the implementation phase of data transmission between the client and the node was particularly focused on the IP conflict problem where the client possessed a private IP and when the client was connected to the node with the help of crossover cables (LAN), the connec- tion could not be established with the server as the node also received the private IP from the client in eth0 which caused the transmission failure as the eth0 was the primary transmission path between the client and server via node. In order to rectify this problem, a public IP interface was set as the de facto standard i.e. lower metric for transmission purpose instead of eth0. This alternative method of correction has been able to solve the afore- mentioned problem.
The result obtained from the project was inline to the desired output we required from this particular project, where the major focus of the pro- ject was to probe our prototype concept against the pre formulated TCP, MPTCP and MPTCP-MS. After a thorough probing in this matter, the ex- pected result has been achieved which has also been shown from figures 4.7 and 4.8 in results section of this report as well. The figures as mentioned above, show that the if two clients send two different sized packets of data
in different rates, the script running within the node will separate the trans- mitted data in terms of packet ID and the path on which the packets flow will be determined within the node in terms of the packet ID to the server. In this project, one way delay factor was taken as a threshold parameter and this project has been able to succeed in achieving one way delay factor as minimum as possible compared to aforementioned technologies.
In multi-path transfer, the most serious issue is the reordering of the pack- ets, which was caused by dissimilarity delays path. In our experiments, we have used two different MBB providers (Telenor and Netcom) with different characteristics. Each provider may have different characteristics in-terms of delays or bandwidths. While packets are transferred through multiple paths, packets transmission using low delay path reach the destin- ation faster than high delay path. This may cause the reordering of packets in the receiver side. If more packets have been reordered, it will create more complex to restoration for the receiver and also required more buffer size. To reorder packets in receiver side in its original form, it may take time so that delay may be increased. In the default MPTCP mechanism, this issue may arise. To solve the reordering of packets, we can assign specific path and send packets with same packetID on the same path. This will minim- ize the reordering issue and give the better result in-terms of delay.
In all of our scenarios, results obtained using normal TCP connection, shows that, it utilizes more delay than other two mechanisms. This is due to, TCP only use one path for packets transmission and may be it uses higher delay path. In the case of default MPTCP connection, it seems better than TCP. It is obvious because it uses multi-path for packet transmission. It is also reliable because if we loose one link we have another link to con- tinue data transmission. Even it uses multi-path it performs quite less than MPTCP-MS, this is because of reordering issue specified earlier. Finally our proposed method MPTCP-MS shows the best results in terms of delay, because it separates the incoming packets from two clients with respective packetID and transmits through the selected interface. The packets in re- ceiver, receives in its original form and don’t need to reorder, so it reduce the delay factor.
One particular astonishing factor realized during the tenure of this project was that, while experimenting with transmission of the data packets, there were several experiments carried out in order to find out any performance issues relating to OWD parameter. While doing these repetitive experi-
ments on MPTCP-MS, OWD was observed to be higher in the first few repetitions however during the progression of repetitions it was observed that the OWD decreased in an explicit pattern where the decrement was openly noticeable. In comparision to TCP and default MPTCP, MPTCP-MS has proved its robustness and OWD factor was found to be minimum as compared to the other two technologies.
The project has been able to meet the agendas set forth, although there were a few hindrances during the course of the project. One major prob- lem faced during the practical implementation of the project was the use of NorNet Edge node, which was not a familiar device for me. The basic working of the device was theoretically understandable however, the prac- tical usage of the device was a bit of a problem as the device was absolutely foreign to my knowledge. Therefore, I needed to invest some time in order to familiarize myself with this device before I was able to operate the device in a capable manner.
As mentioned before, initially the project was structured to design a full- fledged Telemedicine system with transmission capabilities. However, during the course of time, the project was substantially minimized in its scope to focus particularly on the transaction and transmission of data. This transition of the structure of the project was one limiting factor in the proper completion and implementation of the project as there were time constraints due to the fact that the focus of the project was shifted which caused considerable loss of time in terms of research which focused on the full fledged Telemedicine system. In the background section of the report, I had explained a lot regarding the full-fledged Telemedicine system. How- ever, with the shift in focus the information mentioned in the background might not all remain relevant to the project at hand. Even though, this was a limiting factor the project remained on course and within the time limit, which guaranteed timely completion of the project as well as the results obtained from the project has been quite satisfactory as well.
The major focus of the project was to compare the delay factors related to TCP and MPTCP technologies where we conducted several experimental probes in order to find out one-way delay related to both the technologies where we were more focused on MPTCP-MS. The project is practical in its approach, where a prototype device such as Nor-Net Edge node was
used to transmit delay sensitive data and these transmission details were recorded and analyzed in this project in order to generate an unbiased con- clusion generated from the information gathered from several experiments with the device. As per my view, it is paramount that a prototype device such as Nor-Net Edge containing multiple interfaces was necessary for the proper completion of this project. In light of this fact, I believe this was the best approach for the project and it would be wise for any other such projects to embrace this approach.
One major issue that is necessary to discuss regarding this project is the issue of variety of time zones (time synchronization), which may cause dis- parity in time delay calculation within the project. In order to solve this issue of disparity in time delay calculation due to the variety of time zones, one particular solution that I think is creation of a script that will enable both client and server devices to sync from the same NTP server which has somewhat resolved the issue of time difference. However, in order to further minimize this issue, I have also devised and used the OWD nor- malization concept.
Our proposed system, which has also been implemented practically to a greater extent, has been able to provide valuable answers related to trans- mission of different kinds of data in the path desired by the user. This particular outcome will impact the functionalities of transmission of data using TCP and MPTCP, which are the forth-set standards up and until now. This will undoubtedly be a major contributing factor for MPTCP-MS.