Find out how ICT can support biomedical and clinical researchFind out more. From Clever cars to clever farms... Embedded Systems
freezedccp

Freeze-DCCP: Mitigating the Effects of Network Mobility and Wireless Disconnections




Related Publications

Analytical Model

Python implementation

Coming soon.

Model Validation

The model has been verified against a wide range of ns-2 simulations, using the parameters detailed in the Simulations Scenarios section.

To check the number of lost packets, disconnections of up to 300 s were introduced after a variable amount of time (from 10 to 30 s with 0.5 s increments), for link bandwidths of 10, 54 and 100 Mbps (delays from 0.001 s to 0.1 s). The number of packets sent after the disconnections has then been counted.

Similarly, the wasted bandwidth due to the reduced sending rate and the slow adaptation to higher capacities has been verified for handovers to networks with identical or higher bandwidths (same ranges as above). The stationary state RTT, as it is partly caused by queuing, was considered too high to accurately represent that of the newly joined network. The sum of the links two-ways delays was used instead.

nsFreeze-DCCP extension for ns-2

Coming soon.

Simulation Scenarios

All the simulations have been run in ns-2.33, patched with DCCP support [1]. Additional modifications have been made in the TFRC sender to implement the clarified loss average calculation from [2]. The DCCP/TFRC/Freeze agent has been implemented by deriving the DCCP/TFRC C++ class, adding the freezing mechanisms described in the publications.

As we were only interested in the impact of disconnections on the transport layer, it was irrelevant to simulate all the underlying wireless networks as such. Rather, simple wired topologies have been used, as suggested in [3]. All wireless links were modeled as duplex links, particularly the 802.1x ones. This may not be correct for bi-directional data scenarios. Such scenarios, however, have not been studied here.

A router was placed between the sender and the receiver. We refer to the links between the router and the sender (resp. receiver) as ls (resp. lr). Such a topology allowed to transparently disconnect link lr without preventing the sender from trying to transmit packets during the disconnections. DropTail queues the default buffer size (50 pkts) were used.

Disconnections were simulated by manipulating the routing model of ns-2 with the $ns_ rtmodel-at function. The time of a disconnection was chosen, once the system was in a stationary state, from a uniformly distributed variable over a time period of four RTTs. The generic behavior of TFRC and our variant was thus captured. The presented results have been averaged over 20 runs to ensure confidence. The simulations were ended only after the rates had settled. Link characteristics were modified using the $ns_ bandwidth and $ns_ delay commands.

The Freeze-enabled DCCP agent was instructed to suspend its connection locally (i.e. not using the OPT_FREEZE and OPT_UNFREEZE options). The freeze command was given one RTT before the disconnection was scheduled to happen. The unfreeze instruction was given 0.1 ms after the network link was reconnected.

Common Parameters

Unless otherwise stated below, the default parameters for the agents were used, including the packet size s of 500 Bytes.

As our focus was not congestion control per se, Explicit Congestion Notification was disabled.

The current ns-2 implementation of DCCP does not handle ACK vectors bigger than the maximum allowed option size. This was the case in some of the simulations, so ACK vectors have been disabled at large.

The optional timestamp feature of DCCP/TFRC was enabled. This allowed to accurately keep track of the RTT, rather than relying on the Window Counter value specified in [4]. It is advisable to always have it enabled in disconnection-prone scenarios. Indeed, this small scale value is likely to wrap during a disconnection, thus giving a bad estimate of the Round Trip Time which would, in turn result in temporarily wrong values for e.g. Xq.

Finally, the traffic was generated using an FTP agent sending at the maximal possible rate.

Link Characteristics

Real link characteristics have been taken from the literature or protocol specifications. They are summarized in Table 1.

Table 1. Bandwidths and delays of common wireless network technologies.
Technology Bandwidth [MBps] Delay [ms]
UMTS 0.384 125 [5]
802.16 9.5 [6] 40 [7]
802.11b -- g 11 -- 54 10 [8]

Simulations were run to determine the X and R parameters as perceived on these links by TFRC in the stationary state. It was considered that this stationary phase was reached when the cumulative average of the rate reached 95% of the current rate. Table 2 shows the values that served as input for the model and the computation of the unused bandwidth in simulation.

Table 2. Network parameters as observed by the TFRC sender in the stationary phase, reached at Tstat.
Link typeXrecv [MBps] R [s]Tstat [s]
UMTS 0.044 0.96 660.54
802.16 1.10 0.17 264.14
802.11b 1.27 0.05 50.69
802.11g 4.82 0.04 21.67

Disconnections Lengths

Most mobility schemes introduce disconnections of variable duration when handing off from one network to the other. Table 3 lists the disconnection lengths that can be experienced by a mobile node.

Table 3. Disconnections due to mobility
Mobility scheme Duration [s]
MIPv6 2.5 + R

MIPv6 relies on message exchanges over the network to update the binding with the Home Agent. Fast handovers [10] could be used to reduce the disconnection duration. However, packets arriving during the hand-off are buffered at the new access router, which is not desirable for real-time traffic as that would will create latency at the application level upon completion of the handover. Thus, handoff delays will vary depending on the characteristics of the current link [11]. The link delay and resultant RTT are particularly important.

Performance Evaluation

For the real conditions simulations, link ls was configured with the characteristics of the current wireless network. Link lr was arbitrarily set to a 100 Mbps link with 50 ms latency to roughly simulate the rest of a wired connection to a remote peer.

Fairness Assessment

To determine the fairness to TCP of the proposed enhancement, a TCP connection was added in the previous simulation scenario. A TCP/Newreno agent on the router was sending Application/FTP traffic to a sink on the receiver node. The samples, taken after reconnecting, have been averaged over 100 s, discarding the initial rate settlement period.

Linux 2.6 implementation

Coming soon.

References

  1. N-E. Mattsson. A DCCP module for ns-2. Master’s thesis, Luleå Tekniska Universitetet, May 2004. ns-2.33 patch.
  2. S. Floyd, M. Handley, J. Padhye, and J. Widmer. TCP friendly rate control (TFRC): Protocol specification. RFC 5348 (Proposed Standard), Sept. 2008.
  3. A. Gurtov and S. Floyd. Modelling wireless links for transport protocols. ACM SIGCOMM: Computer Communication Review, 34(2), 2004.
  4. S. Floyd, E. Kohler, and J. Padhye. Profile for datagram congestion control (DCCP) congestion control ID 3: TCP-friendly rate control (TFRC). RFC 4342 (Proposed Standard), Sept. 2008.
  5. F. Vacirca, F. Ricciato, and R. Pilz. Large-scale RTT measurements from an operational UMTS/GPRS network. In IEEE WICON ’05, 2005.
  6. O. Grøndalen, P. Grønsund, T. Breivik, and P. Engelstad. Fixed WiMAX field trial measurements and analyses. 16th IST Mobile and Wireless Communications Summit, July 2007.
  7. E. Halepovic, M. Ghaderi, and C. Williamson. TCP over WiMAX: A measurement study. In IEEE MASCOTS ’08, 2008.
  8. T. Karapantelakis and G. Iacovidis. Experimenting with real time applications in an IEEE 802.11b ad hoc network. In IEEE LCN’05, 2005.
  9. J. Jakubiak and Y. Koucheryavy. Precise delay analysis for IEEE 802.11 legacy ad-hoc net- works. IEEE VTC2007-Spring, Apr. 2007.
  10. R. Koodli and C. E. Perkins. Fast handovers and context transfers in mobile networks. ACM SIGCOMM: Computer Communications Review, 31(5), 2001.
  11. J. S. Lee, S. J. Koh, and S. H. Kim. Analysis of handoff delay for mobile IPv6. IEEE VTC2004- Fall, 4, Sept. 2004.