DistOS-2011W User Controlled Bandwidth: How Social Protocols Affect Network Protocols and Our Need for Speed

Abstract

In the past 20 years, advancements in computing have gravitated towards connectivity, specifically the rise of the internet. The last decade (2000 – 2010) has seen a global increase in the number of internet users by over 400%, and as expansion into the Middle East and Africa continues, the total number of people connected to the internet will only grow.[1] As we continue to build computer interfaces which simplify the user experience (iOS, for example) more of the population can make use of computers without knowledge of how a computer works. Specifically, terms like bandwidth or latency mean little to the average computer user in terms of the actual performance of their computer.

This paper will review what distributed computing means to an average user as well as how we can make better use of our networks by providing users with simple to use tools to understand bandwidth and how different applications utilize the finite resource. We will begin with an introduction describing typical internet traffic as well as how users typically interact with the internet. Following the introduction is a look into the need for user controlled bandwidth and what benefits it affords. Next we will examine a particular case study in which households were given a tool to monitor and adjust their bandwidth usage. The subsequent section will examine some current tools for implementing user controlled bandwidth. The final section of the paper provides a discussion on the current state of user controlled bandwidth and what direction it may take in the future.

Introduction

To understand user controlled bandwidth it is important to understand how internet traffic “flows” as well as trends in data movement and user interactions with the internet. A typical user of the internet does not care about concepts such as packets, they simply run applications, like web browsers, completely unaware of the size and duration of their connection to the internet. Most internet traffic is either based on Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). UDP is not a guaranteed delivery protocol, it simply sends packets, regardless of congestion in the network, and does not provide any confirmation of receipt to the sender. Alternatively, TCP provides a delivery system analogous to stream delivery. TCP has a feedback mechanism to control the sending rate, it sends data as fast as it can until there is congestion at which point it scale back the rate, and it also confirms delivery of data.[2]

Due to the congestion control and guaranteed delivery properties, TCP is the delivery method used most frequently on the internet.[3] This makes sense for connections that last a long time, greater than 15 minutes, and/or transmit a lot of data as it allows the congestion control mechanism to provide some form of “fair” sharing of the available bandwidth. However, an analysis of actual internet traffic displays a usage landscape that is not dominated by large, long connections. Most internet streams are very short in duration, less than 15 minutes (98%), and almost half of those streams are less than 2 seconds in duration.[4] This means that the majority of streams on the internet are not actually connected long enough to take advantage of TCP’s congestion control mechanisms.

The remaining 2% of TCP streams, on the other hand, last longer than 15 minutes but account for approximately 50% to 60% of all bytes transmitted. This presents a transmission environment in which we need to consider streams both temporally as well as spatially as these two dimensions have very different affects on the network.[4] It becomes clear why internet traffic follows these patterns when further analysis is focused on how users typically interact with the internet. Although the number of users of the internet has been growing exponentially and similarly the number of web pages on the internet has grown exponentially, typical usage of the internet is fairly conservative. The average user will connect to the internet multiple times but each session is typically short in duration. While connected, users will typically visit a small, well-known group of sites as opposed to exploring new web pages. In fact, users will typically frequent a single website multiple times in a single session.[5]

User Controlled Bandwidth

Is Bandwidth the Correct Measurment for Network Speed?

The average internet user is not concerned with bandwidth or latency; he/she is only interested in how long it will take to complete a task. Typical tasks may include loading a web page, downloading a file, watching a video clip or conversing in a conversation on voice over IP (VoIP). Yet when we purchase an internet package from an internet service provider (ISP), we only get to choose by bandwidth allotment. By marketing internet connections with terms that a network technician would find useful, but to an average user are useless, users are left without a conceptual model for how their internet usage affects their connection “speed”.

Dukkipati and McKeown provide an interesting alternative in Why Flow-Congestion Time is the Right Metric for Congestion Control. A user is not concerned with full utilization of their bandwidth, network fairness or throughput; all they care about is how quickly a task may be completed. Dukkipati and McKeown propose measuring connections based on Flow Completion Time (FCT) which could allow for improvements to the way data is transmitted. As mentioned earlier, typical data streams on the internet do not last long enough to make full use of TCP’s congestion control mechanisms, such as “slow start”. Even worse, because of TCP’s slow start mechanism, many of these short flows have their lives prolonged in multiple orders of magnitude of round trip times (RTTs) causing unnecessary congestion. [6]

In order to combat these issues with TCP, Dukkipati and McKeown suggest adopting a Rate Control Protocol (RCP) which would simulate processor sharing at each router. Using such a protocol each flow would be assigned a single rate and each flow would have the same rate. This rate would be dynamic depending on how many flows are present and the input traffic rate. The benefit of RCP would be that the router no longer needs to maintain per-flow state or per-packet calculations. Furthermore, since there would be no “slow start”, the short streams (which make up 98% of the streams) would no longer have their lifetimes unnecessarily extended.[6]

The issue with altering network connection descriptions from bandwidth to Flow Completion Time is that it is very difficult to guarantee an FCT. However, this may not be such an issue as ISPs routinely advertise bandwidth amounts that are theoretical or are not based on the effect of others on the network sharing the resource. Thus, current ISP descriptions of network “speeds” based on bandwidth may be no more accurate than they would be if based on FCT. The benefit of basing them on FCT, however, is that users would be able to understand what their “expected” rate would be when it is a time limit as opposed to a size limit.