minRTT logics in ProbeRTT mode

[Li Zonglun]

Hi all,

I found something interesting about the minRTT update when BBR is in its ProbeRTT mode. Notice that in the bbr_update_min_rtt function, when the filter_expired is true, BBR simply assigns the value of rate_sample’s rtt_us to bbr->min_rtt_us, which leads to the figure below:

Clearly, the minRTT first increases to a high value due to the filter expiration. At this moment, though BBR enters ProbeRTT mode(BBR MODE=3), the rtt sample is still collected from data sent in other modes(mainly ProbeBW). Therefore, it’s no surprise why the “minRTT” actually is not the minimum value. Later, when the ack of the data sent after BBR entering ProbeRTT arrives, BBR gets its true minimum value. So my question is why not collecting samples after ProbeRTT lasts at least one round, since from this moment the rs->rtt_us value is actually the true minimum rtt value? It won’t raise the minRTT to a high value.

I have modified the bbr_update_min_rtt function a little as follows, where ... means no modification:

...

filter_expired = after(tcp_jiffies32, bbr->min_rtt_stamp + bbr_min_rtt_win_sec * HZ);

if (rs->rtt_us >= 0 && rs->rtt_us < bbr->min_rtt_us) {

    bbr->min_rtt_us = rs->rtt_us;

    bbr->min_rtt_stamp = tcp_jiffies32;

}

...

if (bbr->probe_rtt_round_done) {

    if (rs->rtt_us > 0 && !rs->is_ack_delayed) {

        bbr->min_rtt_us = rs->rtt_us;

        bbr->min_rtt_stamp = tcp_jiffies32;

    }

    bbr_check_probe_rtt_done(sk);

}

...

 I’m not sure whether this causes new problems. However, at least in my controlled environment, it works well: