2-related.tex

\section{Related Work}
\label{s:related}

%With our work sitting at the intersection of highly popular topics of scheduling, congestion control and middleboxes, one can produce a large body of past work related to each topic. However, this unique intersection of topics is also what adds significant novelty to our work. 

\Para{Traditional congestion control}
End hosts employ congestion control algorithms that aim to achieve high throughput and low delay while fairly sharing network resources with other users~\cite{Jacobson88}. 
Each connection runs such an algorithm independently to learn about the network conditions and find the best sending rate.
In \name, a \inbox uses such an algorithm to determine the aggregate's sending rate, rather than the rate of an individual connection. 
The end-hosts continue to use unmodified end-to-end congestion controllers for each connection.

\Para{Aggregating congestion information} 
% something like:
% - congestion control is xyz
% - it is typically done independently by each flow
% - however, many flows from the same sender often traverse the same bottleneck. each flow independently learning about the network is inefficient.
% - as a result, there have been multiple proposals to aggregate cc information: 1,2,3
%However, as noted in prior work, in cases where there are a large number of flows between the same sender and receiver, each flow independently learning about the network is inefficient, and it would make much more sense for them to share information.
There have been multiple proposals to aggregate congestion control information in different contexts: flows sharing the same endpoint~\cite{cm}, flows between two racks within a datacenter~\cite{rackcc}, and flows originating from a large cloud/content provider~\cite{fivecomps}. 
The goal of these approaches is to share information among the various end-to-end flows' congestion controllers, which allows them to better adapt to network conditions. 
%As traffic controllers, however, aggregate congestion control schemes cannot enforce precise traffic scheduling policies due to control overheads \fc{what does this mean?}.
\name has a different goal: to control queueing (and thus enable scheduling) from the edge of the network without interfering with the end-to-end congestion controllers of individual component flows. It is orthogonal to prior proposals on aggregate congestion control.
%\name uses aggregate congestion control in a different way (with a different goal): as a light-weight mechanism to shift the queues from the middle of the network to the edge, without interfering with the end-to-end congestion controllers of individual flows. It is orthogonal to prior proposals on aggregate congestion control.

\Para{Using a middlebox for queue management} Remote Active Queue Management (AQM)~\cite{ardelean} aims reduce VoIP traffic latency by deploying a middlebox at a site's access link that drops packets or injects ECN marks for the remaining flows in order to manipulate their end-to-end congestion control loops. It makes a core assumption that the bottleneck is the site's access link.
%, and because it relies on manipulating end-to-end congestion controllers, its component traffic must have specific characteristics, \ie those of VOIP traffic.
In contrast, \name tackles arbitrary bottleneck locations in the middle of the network. Moreover, unlike Remote AQM, \name is not restricted to a specific queue management policy for a specific traffic class.

%Remote Active Queue Management~\cite{ardelean} proposed to manipulate end-to-end congestion control loops to achieve a traffic control objective by dropping packets or injecting ECN marks. However, it makes the core assumption that the bottleneck is the site's access link, and because it relies on manipulating end-to-end congestion controllers, its component traffic must have specific characteristics, \ie those of VOIP traffic. 
%Instead, \name works with arbitrary bottleneck locations in the middle of the network and imposes an out-of-band control loop which is compatible with any component traffic (\S\ref{s:design}). 
%\radhika{not clear what remote AQM is, how its different from regular AQM, and why it is related. Lets quickly discuss} 
%\fc{not sure if we can say arbitrary -- if bottleneck is outside of the pair, bundler won't do anything. maybe better distinction is just that we target different scenarios and are thus orthogonal.}\an{clarified middle of network}

%A recent proposal~\cite{fivecomps} observes that the majority of today's traffic is owned by a few entities.
%This observation implies that there are large bundles in practice, resulting in greater scheduling opportunities within a bundle. 
%The proposal uses its observation to advocate sharing congestion information across a given domains endhosts. 
%This is orthogonal to our goal of scheduling such traffic by introducing a middlebox without modifying end hosts.

\Para{Overlay networks} \name's motivation is closer to a proposal in overlay networks, OverQoS~\cite{overqos}, which aimed to provide QoS benefits in the Internet by enforcing traffic management policies at the nodes of an already-deployed overlay network~\cite{ron}. 
\name's approach is more lightweight; instead of relying on an overlay network, \name only requires each site to deploy a middlebox, and uses a novel control loop between the middleboxes to facilitate traffic management at the sites. 
%\fc{can we also say something about not modifying traffic so its incrementally deployable?}\an{overlay networks can also claim to not modify traffic and be incrementally deployable, right}
%This simplifies the ``rendezvous'' problem, since \name initializes bundles dynamically (\S\ref{s:design}).
%In addition, \name provides a novel mechanism to \emph{move} the in-network queues, and gain the power to schedule the bundled traffic. 

%\Para{Packet scheduling} There have been some recent efforts towards enabling the benefits of packet scheduling. Most are complementary with \name and could be used as its datapath.
%For example, PIFO~\cite{pifo} is a priority queue for programmable switching chips. 

%However, not only does it require changing  in-network routers, but it also suffers from the issue of an ISP's limited visibility into the traffic to choose desired policies (and limited incentives to enforce them). 
%UPS~\cite{ups} allows different scheduling policies to be expressed from the edge via header initialization, but also requires a change to the routers.
%However, since queuing still occurs in the middle of the network, it relies on the customers targeting a common global objective, or on the network operators isolating different customers' traffic, both of which are difficult to realize. 
%\name provides a solution that does not require any cooperation from downstream networks in other organizations.