Content uploaded by Amine Dhraief
Author content
All content in this area was uploaded by Amine Dhraief on May 10, 2016
Content may be subject to copyright.
A preview of the PDF is not available
The impact of mobile IPv6 on transport protocols an experimental investigation
Abstract and Figures
Mobile IPv6 (MIPv6) is the current standard for end host mobility management in the Internet. In order to provide location management, MIPv6 operates in two different modes while the mobile node (MN) is away from its home. In the first mode, the MN incoming packets are tunneled to the MN current location via the home network. In the second mode, the traffic is exchanged directly between the MN and its peer. In this paper, we evaluate the performance of these two modes on a real testbed. We focus more precisely on the impact of the node movement on running transport sessions.
Figures - uploaded by Amine Dhraief
Author content
All figure content in this area was uploaded by Amine Dhraief
Content may be subject to copyright.
... Among the important issues of TCP in the wireless mobile networks, we mention the confusion between packet losses caused by movement and congestion. In our previous works [3], [2], we studied the impact of MIPv6 node movement on running TCP sessions on real testbed. We highlighted that current TCP implementations in recent Linux kernels do not handle appropriately end-host movement. ...
... Our previous experimental observation [3], [2] showed that TCP application recovery lasts much longer than the handover latency. This is due to the fact that the RTO value may be recently reset just before the handover finishes. ...
MIPv6 is the current IETF standard to manage IPv6 node mobility. While moving, TCP application may stop transferring data due to Internet disconnection. Due to TCP retransmission mechanisms, TCP applications are recovered as soon as problem is vanished. Nevertheless, TCP does not distinguish between losses due to network congestion and losses during end host mobility. Both kinds of losses are treated by the same mechanisms. Hence, the time that takes an application to be recovered is relatively long comparing to the time taken to be attached to a new access router. Therefore, in this paper we propose a novel mechanism that reduces the time of the TCP application recovery by enabling the cooperation between TCP and MIPv6. The proposed enhancement is implemented in OMNeT ++ network simulator. The Application Recovery Time is significantly reduced in dense and sparse networks.
... In this context, it is important to mention that TCP different algorithms confuse between movement and congestion when recovering after packet losses. This was highlighted in our previous work [4,3] when studying the impact of the mobile node's movement on TCP sessions. The reaction of TCP after the packet loss caused by devices movement is the same as its reaction at the diagnosis of a network congestion, i.e. ...
Host and network mobility support mechanisms aim to provide a seamless access to Internet while end users are changing their point of attachment. When a mobile entity roams from a network to another, a handover occurs causing communication session discontinuity degrading real-time application performance. Assuming that such inconvenience is a congestion, TCP recovery is slow and careful. We have previously proposed a cooperation between TCP and MIPv6 and proved its efficiency through OMNeT++ simulations. In this paper, We study its efficiency in the context of mobile networks. Therefore, we implement xNEMO; a compliant implementation of NEtwork MObility Basic Support (NEMO BS) in OMNeT++. Besides, in order to enhance the performance of TCP application, we propose to modify the TCP behaviour after a recovery from a handover. Simulations show that the cooperation between TCP and NEMO BS reduces the Application Recovery Time and enhances the performance of the TCP application.
... IP addresses have a dual role, they are considered at the same time end-host locator and session identification. Hence, without an adequate support, running transport session is broken as a consequence of L3 handover [4]. To ensure transport session survivability upon movement, session identification should remain stable while end-hot locator is changed. ...
The HIP-Based M2M Overlay Network (HBMON) is a virtual, self-organized and secure M2M network built on the top of Internet, composed of scattered mobile devices. A fundamental requirements of this overlay network is to ensure session survivability upon end-host movement. The Host Identity Protocol (HIP) provides a regular mobility support in our M2M Overlay network. However, HIP is not able to handle the simultaneous mobility case, where both communicating end-points simultaneously acquires a new topologically correct IP address. We propose in this paper a novel solution to manage the simultaneous mobility (also known as double jump) of M2M devices within our overlay. For this purpose we enhance the HIP rendez-vous server in order to fully manage the double jump case. We analytically evaluate the signaling cost of our solution. Then, we implement our double jump solution within the OMNeT++ network simulator. Finally, we evaluate the application recovery time of an M2M device experiencing a double jump situation.
... TCP has to wait until the TCP Retransmission Timeout (RTO) timer expiry. TCP does not distinguish between a failure recovery process and the congestion in the currently used path [5] . It adjusts the RTO timer as if it has experience of a congestion phase which explains the plateaus in TCP Application Recovery Time UDP Application Recovery TimeFigure 3: Application recovery time after an outage ...
The machine-to-machine (M2M) technology, is expected to be one of the most promising revenue-generating services. However, to ensure the wide spread of this technology, M2M communications should be secure, fault-tolerant and self-managed. In this work, we add to the M2M gateway the self-healing and self-optimising autonomic capabilities.We couple at the M2M gateway level the host identity protocol (HIP) with the reachability protocol (REAP). REAP enables a selfhealed M2M communication as it detects possible failures and rehomes an M2M session to a new overlay path.We modify REAP to ensure self-optimisedM2Mcommunications. REAP continuously monitors M2M overlay paths and always selects the best available ones.We implement our solution on the OMNeT++ simulator. Results show that M2M sessions effectively resume after an outage. Results also highlight thatM2Msessions autonomically select the best availableM2Moverlay paths.
The emergence of wireless networking necessitates continuous time connectivity to support end-to-end TCP or UDP sessions. Wireless networking does not provide reliable connections to mobile users for real-time traffic such as voice over IP, audio streaming and video streaming. Handover latency in Mobile IPv6 poses many challenges to the research world in terms of disconnecting users while roaming. Many efforts have been made to reduce the handover latency with focus either on layer 2 or layer 3. This paper presents the handover procedure of Mobile IPv6 and investigates various factors affecting the delay during network switch over. In this paper, a testbed environment is presented that includes two different wireless LAN networks using Universal Mobile IP for Linux (UMIP) implementation and Cisco routers. The aim is to present handover latency caused by multiple signals at layer 2 and layer 3 and make recommendations on how to reduce the total handover latency experienced by the MIPv6 protocol. © Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2012.
This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods.
