Hello, dear friends. I wonder there is any optimization to BBR , for the reason of BBR low bandwidth utilization in wireless network with high delay jitter. In my opinion, High delay jitter will cause BBR to underestimate the BDP, thus limit the send rate even if pipeline is not full. Right?So, I wonder, if there is any optimization to improve bw utilization in wireless network with high delay jitter, even in 5G network? Thx a lot.
--
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/bc675976-45f5-4ef6-b337-e693e4d21c6en%40googlegroups.com.
Hi, Neal, thanks for your answer. I still have two questions to discuss with you after having read the two links you mentioned above.1, As mentioned in the second link, BBR's throughput on high-jitter links (especially in cellular) usually matches CUBIC, as demonstrated by the following figure,however, what we can infer from the figure is that, the mean throughput(~14Mbps) is far from the available bw that is greater than 20Mbps as showed in the cumulative distrubution figure. Since CUBIC back off frequently in the LTE network with high error rate, but BBR does not acquire much more throughput than CUBIC, the only reason I can imagine is that BBR is highly affected by high delay jitter although cwnd provision is applied.
Is my understanding right?
and is there any optimization to further improve thoughput in high bw and delay jitter scenario?2, Is there any method to enhance BBR's adaptive ability to high bw and delay jitter? In my opinion, in high bw jitter scenario, window based bw undaption method is too slow to converge to the actual bottleneck bw, when actual bw imcreases, BBR needs at lease 8RTT to catch it, when it decreases, BBR then needs at most 10 RTT to expire the previous bw maximum, anyway it is too slow, causing severe buffer-bloating. In high delay jitter scenario, BBR also will cause bw under utilizaion. So, what is your latest optimizaion to improve the performance in such a high bw and delay jitter network?
Thx a lot,Eric--在2021年7月4日星期日 UTC+8 下午9:59:57<Neal Cardwell> 写道:Yes, BBR includes mechanisms to deal with this kind of jitter. Please see the March 2019 thread on this topic:https://groups.google.com/g/bbr-dev/c/kBZaq98xCC4Our experience is that BBR's throughput on high-jitter links (cellular, wifi, DOCSIS, datacenter ethernet w/ GRO/LRO) is quite good at this point (usually matches CUBIC), and there are others who have documented this as well, e.g.:best,nealOn Sun, Jul 4, 2021 at 8:53 AM Eric xu <ericb...@gmail.com> wrote:Hello, dear friends. I wonder there is any optimization to BBR , for the reason of BBR low bandwidth utilization in wireless network with high delay jitter. In my opinion, High delay jitter will cause BBR to underestimate the BDP, thus limit the send rate even if pipeline is not full. Right?So, I wonder, if there is any optimization to improve bw utilization in wireless network with high delay jitter, even in 5G network? Thx a lot.--
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/bc675976-45f5-4ef6-b337-e693e4d21c6en%40googlegroups.com.
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/303da319-87dd-46c0-928f-cad7f93835f8n%40googlegroups.com.
flent -H $S --socket-stats -x --step-size=.05 -t 1-flow-fq_starlink_noecn-${M}-c
c=${CC} --te=cpu_stats_hosts=$R --te=netstat_hosts=$R -4 --te=qdisc_stats_hosts=
$RS --te=qdisc_stats_interfaces=$RV --te=upload_streams=1 --te=cc_algo=$CC tcp_1
up
pic below
_______________________________________________
Make-wifi-fast mailing list
Make-wi...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wifi-fast
Curious to the idea of wifi providing the opposite of ECN, i.e. my rate selection algorithm just went from one stream to two stream so TCP speed up your feedback loop decisions with a bias to faster?
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CAHb6Lvroqyg22Ax6ChOPYicYTjm_GnFapm8iX_5ae5EbvVEBzQ%40mail.gmail.com.
Thanks for this. Looks interesting. Does ABC (love the acronym) try to optimize throughput, latency or some combination, e.g. network power (throughput/delay)?
Things like roams, seen energy over the last n milliseconds, and "I've lost n TXOP arbitrations over time y" could also have influence on the control feedback loop to TCP. Not sure how TCP gets any of these stats.
None of this is end/end though. It's likely just the last/first hop which I think is probably still useful to TCP designers - not sure.