Martin Bateman

Exploiting Self-Reported Social Networks for Routing in Ubiquitous Computing Environments

Mobile, delay-tolerant, ad hoc and pocket-switched networks may form an important part of future ubiquitous computing environments. Understanding how to efficiently and effectively route information through such networks is an important research challenge, and much recent work has looked at detecting communities and cliques to determine forwarding paths. Such detected communities, however, may miss important aspects. For instance, a user may have strong social ties to another user that they seldom encounter; a detected social network may omit this tie and so produce sub-optimal forwarding paths. Moreover, the delay in detecting communities may slow the bootstrapping of a new delay-tolerant network. This paper explores the use of self-reported social networks for routing in mobile networks in comparison with detected social networks discovered through encounters. Using encounter records from a group of participants carrying sensor motes, we generate detected social networks from these records. We use these networks for routing, and compare these to the social networks which the users have self-reported on a popular social networking website. Using techniques from social network analysis, we find that the two social networks are different. These differences, however, do not lead to a significant impact on delivery ratio, while the self-reported social network leads to a significantly lower cost.

A comparison of TCP behaviour at high speeds using ns-2 and Linux

There is a growing interest in the use of variants of the Transmission Control Protocol (TCP) in high-speed networks. ns-2 has implementations of many of these high-speed TCP variants, as does Linux. ns-2, through an extension, permits the incorporation of Linux TCP code within ns-2 simulations. As these TCP variants become more widely used, users are concerned about how these different variants of TCP might interact in a real network environment -- how fair are these protocol variants to each other (in their use of the available capacity) when sharing the same network. Typically, the answer to this question might be sought through simulation and/or by use of an experimental testbed. So, we compare with TCP NewReno the fairness of the congestion control algorithms for 5 high-speed TCP variants -- BIC, Cubic, Scalable, High-Speed and Hamilton -- on both ns-2 and on an experimental testbed running Linux. In both cases, we use the same TCP code from Linux. We observe some differences between the behaviour of these TCP variants when comparing the testbed results to the results from ns-2, but also note that there is generally good agreement.

Fairness of High-Speed TCP Stacks

We present experimental results evaluating fairness of several proposals to change the TCP congestion control algorithm, in support of operation on high bandwidth-delay- product (BDP) network paths. We examine and compare the fairness of New Reno TCP BIC, cubic, hamilton-TCP, highspeed-TCP and Scalable-TCP. We focus on four different views of fairness: TCP-friendliness RTT-fairness, intra- and inter-protocol fairness.

TCP Testing: How Well Does ns2 Match Reality?

New transport protocols continue to appear as alternatives to the Transmission Control Protocol (TCP). Many of these are designed to address TCP’s inefficiency in operating over paths with a high bandwidth-delay product (BDP). To test these new protocols, especially comparatively, and to understand their interactions, extensions to the ns2 simulator allow real code from the linux kernel to be used within the ns2 simulations. However, how does the performance of such configurations compare to test-bed experiments of the same configuration? Although, anecdotally, there are often comments within the research community about such issues, there are no studies that quantify the differences for a specific protocol suite. Using a simple testbed, we assess four different transport protocols in a comparative study to examine how well ns2 matches reality. Our tests are all conducted at 100Mb/s over a wide range of delay and router buffer conditions: end-to-end delays from 25ms to 400ms, with end-to-end path buffering of 20% to 100% of the BDP. We find that in our simple configuration, there are significant differences in performance between ns2 and the testbed.

Revisiting inter-flow fairness

Many new transport protocols are being defined, including, for example, variants of the Transmission Control Protocol (TCP), to better match the requirements of new applications. A key issue in the evaluation of protocol flows, in terms of their performance, is how fair they are to other flows. Specifically, it is important to understand how a mix of existing and/or new protocols will interact with each other when using the same network resources. Such observations help to inform protocol design, and allow an assessment of potential impacts on users. We present a simple, yet effective, methodology for examining a specific case of inter-flow fairness based solely on measurements of flow performance. As well as using an existing fairness metric, we propose a new metric which provides a richer information summary for the evaluation of fairness.

Transport Protocol Throughput Fairness

Interest continues to grow in alternative transport protocols to the Transmission Control Protocol (TCP). These alternatives include protocols designed to give greater efficiency in high-speed, high-delay environments (so-called high-speed TCP variants), and protocols that provide congestion control without reliability. For the former category, along with the deployed base of ‘vanilla’ TCP – TCP NewReno – the TCP variants BIC and CUBIC are widely used within Linux: for the latter category, the Datagram Congestion Control Protocol (DCCP) is currently on the IETF Standards Track. It is clear that future traffic patterns will consist of a mix of flows from these protocols (and others). So, it is important for users and network operators to be aware of the impact that these protocols may have on users. We show the measurement of fairness in throughput performance of DCCP Congestion Control ID 2 (CCID2) relative to TCP NewReno, and variants Binary Increase Congestion control (BIC), CUBIC and Compound, all in “out-of-the box” configurations. We use a testbed and endto- end measurements to assess overall throughput, and also to assess fairness – how well these protocols might respond to each other when operating over the same end-to-end network path. We find that, in our testbed, DCCP CCID2 shows good fairness with NewReno, while BIC, CUBIC and Compound show unfairness above round-trip times of 25ms.

END TO END ADAPTATION FOR THE WEB - Matching Content to Client Connections

The size and heterogeneity of the Internet means that the bandwidth available for a particular download may range from many megabits per second to a few kilobits. Yet Web Servers today provide a one size fits all service and consequently the delay experienced by users accessing the same Web Page may range from a few milliseconds to minutes. This paper presents a framework for making Web Servers aware of the Quality of Service that is likely to be available for a user session, by utilizing measurements of past traffic conditions. The Web Server adapts the fidelity of content delivered to users in order to control the delay experienced and thereby optimize the browsing experience. Where high bandwidth connectivity and low congestion exist high fidelity content will be delivered, where the connectivity is low bandwidth or the path congested lower fidelity content will be served and delay controlled.

Simple, Weakly-coupled, Invisible Middleware (SWIM)

One of the operational goals of a middleware platform is to provide a mechanism of distributing computation requests in a way that hides from the programmer the complexity of the underlying systems platform. This means that distribution mechanisms used to harness a set of computer and network resources should not expose to the programmer the detailed systems aspects which are unrelated to their application. Ideally, the programmer should be left to concentrate on the functionality of his/her application without having to be concerned with how the distribution is achieved or how the resources are used. However, this is not true today: programmers need to be aware of details of the middleware in use and are constrained by it in the design of their application, e.g. API constraints. We present a proof-of-concept demonstration of a middleware platform that imposes absolutely no constraints on the programmer apart form those used in the programming language itself. We demonstrate the efficacy of our approach with a prototype implementation in Java, running on a cluster of 20 nodes with a performance comparison with XML-RPC and Java-RMI.

Realising real time multimedia groupware on the web

Real-time audio and video conferencing has not yet been satisfactorily integrated into web-based groupware environments. Conferencing tools are at best only loosely linked to other parts of a shared working environment. This is mainly due to the special Quality of Service (QoS) requirements that these types of resources demand. This paper describes an approach to overcoming this problem by integrating the management of video and audio conferences into the resource allocation mechanism of an existing web-based groupware framework. The issue of adaptation is discussed and a means of initialising multimedia session parameters based on predicted QoS is described. In addition to linking audio and video media rendering quality to the predicted network QoS, the use of models to reduce bandwidth is also explored, replacing video content with control data. Component technologies utilised include the TAGS groupware framework, the Java Media Framework, a Conference Control Architecture and VRML-based avatars that can intermix with real actors.