robust.tex

\subsection{Impact of Cross Traffic}\label{s:robust:cross}

Can \name successfully revert to status-quo performance in the presence of buffer-filling cross traffic, then resume providing benefits once that cross traffic leaves?
In Figure~\ref{fig:eval:bigexp}, we show this scenario.
At first, the link is occupied only by \name's traffic, similar to the setup described in \S\ref{s:eval:setup}.
At time $t=60$~sec, a buffer-filling cross traffic flow arrives.
\name detects its presence (indicated by the gray shading) and starts pushing more packets into the network to compete fairly, reverting back to performance that is slightly worse than Status Quo (median FCT for short flows is \bigexpElasticSlowdownWorseness higher). 
Performance is slightly worse because of the $10$ms queue that \name continues to maintain at its \inbox for active probing to detect the cross-traffic's departure, as described in \S\ref{s:queue-ctl}.
\footnote{We believe the benefits provided by \name in the more common regime with no competing buffer-filling cross traffic are substantial enough to make up for slight degradation in these specific scenarios.}
At time $t=120$sec, the buffer-filling flow stops and non-buffer-filling traffic starts, generated from the same distribution as \name as described in \S\ref{s:eval:setup}.
\name correctly detects that it is safe to resume delay-control, and continues providing scheduling benefits.
For the remainder of this subsection, we present three micro-benchmarks which dig deeper into the latter two scenarios, where cross traffic can affect \name's performance. 
We present results with both Nimbus and Copa being used as the congestion control algorithm at the \inbox. 
\cut{In \S\ref{s:eval:offeredload} we present further results on how well \name retains benefits with varying amounts of offered load.}

\input{inelastic-cross}
\paragrapha{Mix of flow sizes} 
We first consider in Figure~\ref{fig:robust:cr-inelastic} the case \name traffic is most likely to encounter, where the cross traffic comprises of finite-length flows up to a few MBs.
We draw both \name's traffic and the cross traffic from the same measured distribution of web requests described in \S\ref{s:eval:setup}.
We fix \name's offered load at a constant $48$ Mbit/s and vary the cross traffic's offered load from $6$ to $42$ Mbit/s.

While flows are often short, they sometimes exit slow start. With sufficient offered load, they can cause queueing in the aggregate. 
Observe that the \baseline FCTs increase steadily as the cross traffic's offered load increases: this is due to the aggregate queueing effect.
When this happens, Bundler's delay-based rate controller could temporarily lower its rate below the aggregate fair share of the bundled traffic.
Importantly, this throughput reduction is short-lived because the queueing is short-lived, and long-term Bundler throughput is not reduced.
We believe that this trade-off (short-term throughput reduction for better delay) is a good one. 
The lower delay helps the short flows in the bundle, while the large flows in the bundle are not affected by the short-term throughput reduction. 
``Mid-sized'' flows in the bundle can be affected if \name sacrifices throughput for too long. 
By design, however, \name detects such cross-traffic and disables its delay-control mechanism in response.

\input{elastic-cross}
\paragrapha{Persistent elastic flows} 
We now evaluate how \name's throughput is impacted due to competition from varying amounts of persistent elastic cross-traffic. 
As discussed in \S\ref{s:queue-ctl}, we believe this synthetic scenario is rare in practice, but when it does occur, \name cannot provide benefits, and since it must ``hold back'' some queue to detect when the cross-traffic subsides, its traffic will experience RTT inflation.
Indeed, Figure~\ref{fig:robust:cr-elastic} shows that 
the component flows in the bundle experience  \bundlerElasticTputWorseness less throughput on average. 
The impact varies from \bundlerElasticTputWorsenessTen lower throughput with 10 competing flows to \bundlerElasticTputWorsenessFifty lower with 50. 

\input{twobundler}
\paragrapha{Competing Bundles} Last, we evaluate the case where flows from multiple bundles compete with one another. 
In Figure~\ref{fig:robust:twobundler}, we show the performance with two bundles of traffic competing with one another at the same bottleneck link. 
Both bundles comprise of web requests along with a backlogged Cubic flow. 
%Even in the presence of this buffer-filling cross traffic, 
%\radhika{??? i believe the backlog flow is in the bundles and not outside it}
%\an{yes, it is, that's why the perf is good. I agree we should reword, it is confusing}
Both bundles maintain low queueing in the network and successfully control the queues at the \inbox.
Thus, \name provides benefits for both bundles, even when the amount of traffic in each bundle is different.  

\subsection{Impact of Congestion Control}\label{s:eval:cc}

%\an{I have cut down this subsection: removed the e2e congestion control figure and replaced with inline text}
We now evaluate the impact of a different congestion control algorithm running at the \inbox and at the endhosts.

\input{congestion-control}

\Para{\capinbox congestion control} So far we have evaluated \name by running Copa~\cite{copa} at the \inbox. 
Figure~\ref{fig:eval:cc} shows \name's performance with other congestion control algorithms (namely, Nimbus's BasicDelay~\cite{nimbus-arxiv} and BBR~\cite{bbr}), and using SFQ scheduling. 
We find that using BasicDelay provides similar benefits over \baseline as Copa. 
BBR, on the other hand, performs slightly worse than \baseline. 
This is because it pushes packets into the network more aggressively than the other schemes, resulting in a bigger in-network queue.
This, combined with the queue built at the \name, results in the endhosts experiencing higher queueing delays than \baseline. This shows that the choice of congestion control algorithm, and its ability to maintain small queues in the network, plays an important role. 

\Para{Endhost congestion control} We used Cubic congestion control at the endhosts for our experiments so far. When we configure endhosts to use Reno or BBR, \name's benefits remain: \name achieves 58\% lower FCTs in the median compared to the updated \baseline where the endhosts use BBR. 
This shows that \name is compatible with multiple endhost congestion control algorithms.
%This is primarily because in the \baseline, using BBR causes endhosts to achieve 66\% worse median slowdown ($1.62$ with Cubic to $2.68$ with BBR); \name's slowdown is only 5\% worse when endhosts use BBR ($1.08$ with Cubic to $1.14$ with BBR). 

\cut{
\input{e2e}
\Para{Endhost congestion control} 
We used Cubic congestion control at the endhosts for our experiments so far. When we configure endhosts to use Reno or BBR (as implemented in Linux $4.13$), \name's benefits remain (Figure~\ref{fig:eval:traffic}).
%: in Figure~\ref{fig:eval:traffic}, \name achieves 58\% lower FCTs in the median compared to the updated \baseline where the endhosts use BBR. 
%This is primarily because in the \baseline using BBR causes endhosts to achieve 66\% worse median slowdown ($1.62$ with Cubic to $2.68$ with BBR); \name's slowdown is only 5\% worse when endhosts use BBR ($1.08$ with Cubic to $1.14$ with BBR). 
This shows that \name is compatible with multiple endhost congestion control algorithms.
}