Is there an issue on windowed(10s) min_rtt recording?

[Tao X]

According to the documents about BBR, it should track the min_rtt within 10 seconds.

But as the implementation in TCP, shown below:

 

static void bbr_update_min_rtt(struct sock *sk, const struct rate_sample *rs)
{
struct tcp_sock *tp = tcp_sk(sk);
struct bbr *bbr = inet_csk_ca(sk);
bool filter_expired;
/* Track min RTT seen in the min_rtt_win_sec filter window: */
filter_expired = after(tcp_time_stamp,
      bbr->min_rtt_stamp + bbr_min_rtt_win_sec * HZ);
if (rs->rtt_us >= 0 &&
   (rs->rtt_us <= bbr->min_rtt_us || filter_expired)) {
bbr->min_rtt_us = rs->rtt_us;
bbr->min_rtt_stamp = tcp_time_stamp;
}

 when filter_expired is true, it ignores all data, and just take it as beginning.

Is this a bug or is there any other consideration?

Why not reuse the win_minmax codes here?

Thanks!

--

XTao

[Neal Cardwell]

The current approach for min_rtt tracking was a conscious design decision to simplify the code, overall, and save space.

During development we initially used the win_minmax code for the BBR min_rtt estimate. However, we found in experiments that the win_minmax estimator was not a good fit for coordinating PROBE_RTT modes across different flows, because small differences in min_rtt samples could cause big differences in estimates about when the min_rtt in the last 10 second window occurred.

So in out experiments it seemed that if we used win_minmax for min_rtt then the space requirements would be: (a) 3 * 2 * 4 bytes for win_minmax for min_rtt, and then (b) 2 * 4 bytes for coordinating the phase of PROBE_RTT modes. That would be 32 bytes overall.

With our current approach, we essentially only use 2 * 4 = 8 bytes (for min_rtt_us and min_rtt_stamp).

Another consideration is that BBR behavior is usually governed by the pacing rate, which is based on the bandwidth estimate. The min_rtt mainly just comes into play in setting the cwnd, which is only a "back-stop" that does not usually govern behavior. So spending the extra space for a win_minmax to track min_rtt didn't seem like an appealing trade-off.

neal

[Tao X]

Hi, neal

Thank you for your explanation.

As you said, the BBR works hard on adjust the pacing_rate, and cwnd, the main output of conventional congestion control methods, becomes an assistant role.

Dose this imply cwnd would be big enough in most time?

--

XTao

[Neal Cardwell]

On Tue, Dec 6, 2016 at 1:43 AM, Tao X <g.xi...@gmail.com> wrote:

Hi, neal

Thank you for your explanation.

As you said, the BBR works hard on adjust the pacing_rate, and cwnd, the main output of conventional congestion control methods, becomes an assistant role.

Dose this imply cwnd would be big enough in most time?

Yes, exactly. In our experience the cwnd is usually big enough to not be the limiting factor for performance.

neal