Subject: Re: [rmcat] rmcat Digest, Vol 10, Issue 6

From: Keith Winstein <[email-masked]>
Date: Sat, 8 Jun 2013 21:42:15 +0200

Hello,

I am on this list and we're happy to discuss Sprout with anybody. An
early version of this work was presented at the IAB real-time
congestion control summit back in Vancouver so it may sound familiar.

One thing RMCAT might be interested in is the evaluation strategy. We
collected a bunch of network traces that we got from saturating
various cellular links in both directions simultaneously. (To do this
well, we think it requires TWO cell phones connected to a single
laptop -- one phone is the "device under test," and gets its uplink
and downlink saturated so there is >750 ms of standing queue in each
direction. The second phone is left uncongested and is used to control
the feedback loop so we don't accumulate TOO much standing queue in
either direction so that the network will shut us down.)

Then we take those traces back into the lab (or a virtual machine) and
set up a device with two network interfaces, that accepts packets and
puts them at the tail of a queue to leave the other network interface.
Packets are dequeued and sent whenever they were in the
earlier-recorded trace. (Plus some minRTT in each direction, 20 ms in
our case.)

We think this is a good way to *repeatably* test how rate-control
algorithms perform over an "almost-infinite-buffer" cellular-type link
with variable link speed. Otherwise it's very hard to get reproducible
conditions!

We're happy to share our traces, code, etc. with the RMCAT community
if anybody is interested. Actually we put this whole testing setup in
an EC2 virtual machine and made it a homework assignment last semester
in a networking class, asking students to make a better
congestion-control scheme and then run them over this emulated
cellular network: http://6829.keithw.org/ps2/

==

Re: Sprout itself, I think there's probably a few major ideas that
explain why it gets the performance it does on these links:

(1) Sprout has an explicit goal -- maximize throughput while bounding
delay at < 100 ms with 95% probability.

(2) The algorithm is designed from the start for two behaviors of the
network path that are common on cellular links but weren't common 20
years ago -- namely, the network never drops a packet, and the link
speed varies quickly. Essentially Sprout assumes bufferbloat.

(3) And, of course, Sprout benefits from some simplifying assumptions
-- in particular that it is the only flow on the link! If you want to
run multiple competing flows, we have results on running them *inside*
Sprout, but not alongside. We have some forthcoming work that deals
with fairness in a more rigorous fashion, and my colleagues are
working on some extensions to Sprout to deal with multiple flows at
once. But this paper hasn't yet grappled with those issues.

Grateful for your interest!

Cheers,
Keith

On Sat, Jun 8, 2013 at 9:02 PM,  <[email-masked]> wrote:
> ---------- Forwarded message ----------
> From: Fu Jiantao <[email-masked]>
> To: rmcat WG <[email-masked]>
> Cc:
> Date: Sat, 8 Jun 2013 17:29:16 +0800
> Subject: [rmcat] Does any one give sprout a try
> Sprout seems very impressive according to the test report.
>
> http://alfalfa.mit.edu/#paper
>
> More details below
> -----------------------------------
>
> Sprout is an end-to-end transport protocol for interactive
> applications that desire high throughput and low delay. Sprout works
> well over cellular wireless networks, where link speeds change
> dramatically with time, and current protocols build up multi-second
> queues in network gateways. Sprout does not use TCP-style reactive
> congestion control; instead the receiver observes the packet arrival
> times to infer the uncertain dynamics of the network path. This
> inference is used to forecast how many bytes may be sent by the
> sender, while bounding the risk that packets will be delayed inside
> the network for too long.
>
> In evaluations on traces from four commercial LTE and 3G networks,
> Sprout, compared with Skype, reduced self-inﬂicted end-to-end delay by
> a factor of 7.9 and achieved 2.2 the transmitted bit rate on average.
> Compared with Google’s Hangout, Sprout reduced delay by a factor of
> 7.2 while achieving 4.4 the bit rate, and compared with Apple’s
> Facetime, Sprout reduced delay by a factor of 8.7 with 1.9 the bit
> rate.
>
> Although it is end-to-end, Sprout matched or outperformed TCP Cubic
> running over the CoDel active queue management algorithm, which
> requires changes to cellular carrier equipment to deploy. We also
> tested Sprout as a tunnel to carry competing interactive and bulk
> trafﬁc (Skype and TCP Cubic), and found that Sprout was able to
> isolate client application ﬂows from one another.
>
>