How does BBR compare to PCC?

[Prakhar Goel]

Hello All,

The PCC congestion control algorithm is something I came across a few years ago and really liked. 

A paper describing it is here: https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-dong.pdf

It works by trying out a high and low send rate and collecting information on RTT, BW, and packet drops and then uses a fitness function to determine what to do.

This sounds very similar to what BBR is doing (to me at least).

Any thoughts on how the two algorithms compare?

PS. TIMELY is another algorithm that's similar (this time for minimizing buffer-bloat and latencies in data centers). It's offered as a better alternative to ECN (smoother operation and no need for protocol changes). That paper is here: https://research.google.com/pubs/pub43840.html

--

________________

Regards,

Prakhar Goel

[Neal Cardwell]

> https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-dong.pdf

Yes, we are aware of PCC as well. This PCC paper described some nice improvements relative to loss-based congestion control.

There are some similarities between PCC, as it is described here, and BBR. But there are also big differences.

In my mind, the biggest similarities are an overall preference for rate-based control mechanisms, an emphasis on probing the network to inform control decisions, the incorporation of goodput as a core measurement to guide these control decisions, and a goal of being resilient to incidental packet losses that are not indicative of a persistently full bottleneck.

In my mind, the biggest differences revolve around the core framework for modeling the system and controlling behavior:

o PCC treats the network as a black box, where the sender does

  random  rate changing experiments to adjust the sending rate

  according to a utility function that incorporates both throughput

  and packet loss, but is largely "loss-based" (in its own terms;

  see section 2.3). There does not seem to be a bound

  for in-flight data, as it is described in the NSDI paper.

o BBR tries to build an explicit model of the network path, with

  estimates of the bandwidth available to the flow and the round-trip

  propagation time, to inform its control decisions about pacing rate

  and a bound for in-flight data.

Other specific thoughts about PCC:

o The PCC NSDI paper does not seem to mention any bound on the

  amount  of data in flight (cwnd, or a similar mechanism). This suggest

  that  there is no such bound, which suggests that if the bandwidth

  available to a flow decreases significantly then a substantial queue

  would rapidly build, causing high delays and packet loss.

o The PCC utility function incorporates throughput and loss rate, but

  not delay. This fact, together with the apparent lack of bound on

  in-flight data, suggests that the algorithm is likely vulnerable to

  unknowingly operating with persistently big queues and high queueing

  delays, with no apparent mechanism for exiting this operating

  regime.

o The shape of the PCC utility function would seem to tend to drive

  the system to operate near a full queue. In multi-flow scenarios the

  throughput a flow gets is roughly proportional to its share of queue

  slots, which means that a flow's throughput will grow as a function

  of its sending rate. Given that the PCC utility function rewards

  throughput but does not penalize delay, it seems that the dynamics

  of the PCC algorithm described in that paper would tend to drive the

  system to oscillate around a full bottleneck buffer, with delay near

  the maximum potential delay offered on that path, and periodic loss

  causing the largely "loss-based" PCC utility function to conclude that

  sending faster greatly increases loss but not throughput.

That said, I suspect that there are important details about PCC that

are not captured in that NSDI paper. Furthermore, I gather the authors

of PCC have continued to work in this area, so I suspect PCC has

evolved well past the state described in that paper, much as we are

continuing to evolve BBR.

But I hope that helps sketch out some similarities and differences.

cheers,

neal

--
You received this message because you are subscribed to the Google Groups "BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbr-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yuchung Cheng]

re:TIMELY vs BBR

This is often a mis-understood part of BBR: BBR currently does not use delay/RTT as a signal for congestion. This is the exact opposite of TIMELY. But fundamentally BBR can use delay, loss, or even ECN if it can distill accurate and reliable network congestion signals from these events, which is what we've been working on.

Larry's New Vegas has some similar design philosophy like BBR, with a focus on data-center transactions (http://www.brakmo.org/networking/tcp-nv/TCPNV.html) It's also available on Linux.

[Prakhar Goel]

Thanks a lot for this Neal. Very interesting.

Just one nitpick: it seems unfair to claim that PCC doesn't consider buffer bloat when section 4.4 covers this explicitly.

Thanks.

-- PG

[Neal Cardwell]

On Mon, May 8, 2017 at 4:45 PM, Prakhar Goel <newt...@gmail.com> wrote:

Thanks a lot for this Neal. Very interesting.

Just one nitpick: it seems unfair to claim that PCC doesn't consider buffer bloat when section 4.4 covers this explicitly.

Yes, section 4.4 discusses bufferbloat. The paper says:

  ... by literally

  changing one line of code that describes the utility

  function, PCC can flip from “loss-based” (§2.2) to

  “latency-based” (§4.4) and thus caters to different applications’

  objectives without the complexity and cost of

  programmable AQMs [47]. That said, alternate utility

  functions are a largely unexplored area of PCC; in this

  work, we evaluate alternate utility functions only in the

  context of fair queueing (§4.4).

So PCC's story for addressing bufferbloat seems to involve an alternate/experimental utility function that is not the main utility function described and evaluated in the paper. The paper does not seem to address how the world's socket-based applications would be modified to choose between “loss-based” and “latency-based” utility functions for PCC, or what the fairness properties would be for a mix of “loss-based” and “latency-based” PCC flows, or a mix of “latency-based” PCC flows attempting to coexist with Reno/CUBIC in FIFO queues.

neal