how to make inflight to convergency 1 BDP when inflight is 2 BDP currently

[卞明坤]

In this paper “ BBR: Congestion-Based Congestion Control  "https://queue.acm.org/detail.cfm?id=3022184”, figure 3 says that:

Figure 3 shows the effect on a 10-Mbps, 40-ms flow of BtlBw abruptly doubling to 20 Mbps after 20 seconds of steady operation (left graph) then dropping to 10 Mbps after another 20 seconds of steady operation at 20 Mbps (right graph).  

I have a question that how inflight can drop from 100KB to 50KB at 42 second?

Stable ack lead to max_bw 10Mbps at 42 second, so sender can send at a rate of 10Mbps，cwnd is 2*bdp which is 100KB.

Assuming in the DOWN cycle of PROBE_BW， cwnd and inflight is 2*bdp， then sender will

send at a rate of 75% * max_bw,  so the inflight is droped.

But in the following cycle，the inflight is smaller than 2*bdp， but bigger than bdp， so

2*bdp - inflight  > 0, bbr can send  which have enough quota，we can assume that every ack which have no delay can trigger a transmission，because ack rate is 10Mbps， so

send rate is the same of 10Mbps.

So how I should understand this question?

Thanks.

[Neal Cardwell]

Hi,

> I have a question that how inflight can drop from 100KB to 50KB at 42 second?

Thanks for your question. My reading of your question is that there are two aspects of the graph that you may be referring to.

If you are referring to the transition at exactly t=42 seconds, the inflight drops from 200 KBytes down to 100 KBytes at t=42 secs due to the cwnd dropping from a 200KByte value adapted to 20Mbps down to a 100KByte value adapted to 10Mbps.

The 200KB value is from:

  cwnd_20Mbit = 2 * Estimated_BDP = 2 * BtlBw * RTprop = 2 * 20Mbps * 40ms = 200KByte

The 100KB value is from:

  cwnd_10Mbit = 2 * Estimated_BDP = 2 * BtlBw * RTprop = 2 * 10Mbps * 40ms = 100KByte

If you are referring to the inflight reduction from roughly 100KBytes to 50KBytes between t=42 secs and t=44 secs, then that is because the BBR pacing rate is computed to be 1% lower than the nominal value computed by pacing_gain * BtlBw. This is done in order to gradually drain any excess queue. Please see the comment for bbr_pacing_margin_percent in the Linux TCP BBR code.

Hope that helps clarify.

best,

neal

ps: Below is a copy of the figure, for quick reference:

--
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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/f37308d7-4687-4b1a-9741-4c5c2b86c2a9n%40googlegroups.com.

[Tong]

Hi Neal, 

> If you are referring to the inflight reduction from roughly 100KBytes to 50KBytes between t=42 secs and t=44 secs, then that is because the BBR pacing rate is computed to be 1% lower than the nominal value computed by pacing_gain * BtlBw. This is done in order to gradually drain any excess queue. Please see the comment for bbr_pacing_margin_percent in the Linux TCP BBR code.  

Thank you for the detailed reply. I also have the similar doubt before. Here I have a further question about how to compute the convergence time. As I understand, we can drain 0.01* 50 KByte at the queue for each RTT. So  during t=42 secs and t=44 secs (50 RTTs),  we can only drain 0.5*50 KByte at the queue in total. But it seems in the Figure it has drained 1.0*50 KByte. Is there anything else that I have missed?

-Tong

[Neal Cardwell]

Hi,

By my quick calculations, the gradual draining of the queue over the 2-second period between t=42 and t=44 secs in this test is exactly expected if the pacing rate is, on average, 2% below the delivery rate. (The Python simulation script I used, and a portion of its output are pasted below.)

I'm not sure why that early version of Linux TCP BBRv1 had a de facto behavior of pacing at  2% below the delivery rate, rather than the expected 1%. I suspect it could be deduced from auditing the pacing rate and pacing implementations of that era of the code. Since the pacing rate and pacing implementation for Linux TCP have switched to a very different model, EDT, in Fall 2018, it probably makes sense to focus any investigation in that area on a more recent version of BBR.

best,

neal

ps: Python script and excerpt of output:

$ cat  ./q_drain_sim.py
#!/usr/bin/python

link_rate_pps   = 10*1000*1000 / (1514*8)

pacing_haircut = 0.98
pacing_rate_pps = link_rate_pps * pacing_haircut

bdp_packets = link_rate_pps * .040

inflight_packets = 2 * bdp_packets
queue_packets = inflight_packets - bdp_packets

round_trip = 0
elapsed = .010 # simulate 10ms at a time
t = 0
while queue_packets > 0:
    # How many packets does the link forward in this interval?
    link_forwarded  = link_rate_pps   * elapsed
    # How many packets does the sender send in this interval?
    pacing_released = pacing_rate_pps * elapsed

    # Update the queue occupancy:
    queue_packets += pacing_released
    queue_packets -= link_forwarded

    print 't=', t, ' queue_packets=', queue_packets

    t = t + elapsed

$./q_drain_sim.py
t= 0  queue_packets= 32.835
t= 0.01  queue_packets= 32.67
t= 0.02  queue_packets= 32.505
t= 0.03  queue_packets= 32.34
t= 0.04  queue_packets= 32.175
t= 0.05  queue_packets= 32.01

...

t= 1.96  queue_packets= 0.495
t= 1.97  queue_packets= 0.33
t= 1.98  queue_packets= 0.165
t= 1.99  queue_packets= 1.70530256582e-13

 

On Tue, Dec 1, 2020 at 9:56 AM 卞明坤 <bianm...@gmail.com> wrote:

Hi Neal,

    Thank you very much. I have the same question of "Tong",  and I have another  problem：

     In second 40~42s， the rtt is about 160ms， I think the time “160ms” can be computed as following：

     1. inflight  = 2 * Estimated_BDP = 2 * BtlBw * RTprop = 2 * 20Mbps * 40ms = 200KByte， so seq1 will send  when ack1  arrived  , then  seq1 - ack1 = inflight = 200KB， then ack1 and delived1 is both  D1，seq1 is D1 + 200KB

     2. deliverd is D2 when seq1‘s ack  arrive，D2 = D1 + 10Mbps*rtt，  then rate = (D2 - D1)/rtt = 10Mbps.

     3.(seq1 - D1)/rtt = 200KB/rtt = rate = 10Mbps, then rtt = 160ms.

     

     Is there a problem with this calculation？

     Thanks.

在2020年12月1日星期二 UTC+8 上午1:14:09<Neal Cardwell> 写道：

To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/352b6930-b5f9-4fb7-bf83-83c82439e752n%40googlegroups.com.