Subject: [iccrg] BBR question (was: Re: Bufferbloat and Congestion Control)

From: Toerless Eckert <[email-masked]>
Date: Fri, 31 Mar 2017 17:03:36 +0200

> > One relevant alternative I have not seen mentioned in this thread is
> > BBR congestion control. (For BBR info, including the CACM paper and
> > links to the BBR talks at the last 2 ICCRG sessions, see:
> > https://groups.google.com/d/forum/bbr-dev )

One question i have about BBR for which i could not figure out the answer
conclusively from reading the papers:

Assume you a video flow (over BBR) where the sender sends eg: once every 1/60
second a burst of packets - eg: video frame - for simplicity say those bursts
have all the same size, and the average bitrate of such a flow is eg: 10 Mbps.

We put eg: 5 such flows across a 100 Mbps paths, so no ongoing congestion.
With TCP,no-BBR i would see TCP window sized bursts (aka: RTT plays a role), but
what would i see with BBR ? I understand how BBR would be pacing packets to
minimize those bursts whenever there is actual congestion, but in this case
there is no ongoing congestion: 50 Mbps aggregate on 100 Mbps path. Would i
still see pacing, or would each of these flows burstyness be similar or equal to
pre-BBR TCP ?

Thanks a lot
    Cheers
        Toerless

---

From: Neal Cardwell <[email-masked]>
Date: Fri, 31 Mar 2017 12:46:19 -0400

> still see pacing, or would each of these flows burstyness be similar or equal to

In BBR, pacing is the primary mechanism for controlling the in-flight
packets, and cwnd is a fallback.  So, in this scenario, you would
still see BBR pacing out the packets for each of the chunks written 60
times per second. BBR paces in order to try to match the sending rate
to the available bandwidth at the bottleneck, in order to reduce
queuing, to reduce queuing delays and packet loss.

The exact level of burstiness you would see in this case with BBR
would depend on the quantization scheme used by the pacing
implementation involved. For example, in this scenario the Linux TCP
stack would aim to pace out a 2-packet TSO burst roughly every 2ms.

It should also be said that some pre-BBR TCP implementations could
also employ pacing. Google used paced TCP CUBIC for a number of years
before switching to BBR; see Yuchung and Eric's presentation from IETF
88:
  https://www.ietf.org/proceedings/88/slides/slides-88-tcpm-9.pdf

neal