TcpBbr problem

[Ahmed Musa]

Hello,

 I have encountered some weird behavior while running test experiments with TcpBbr in NS-3.35.
BBR seems to perform well in terms of throughput as expected when I set the queue size on the router to be >= 2BDP. When the queue size is less than 2BDP, BBR sometimes behaves normally and sometimes it does not. 

I could not figure out the pattern yet for when it works and when it does not when I set the queue size to be less than 2BDP. In this experiment, I played around with changing the min RTO value as shown in the figure legends. Is this correct expected behavior for BBR to drop its throughput and not recover as shown in the first plot or is there a problem? In the second plot, you can see BBR's normal behavior when the queue size is 2BDP. If it is the expected behavior, is there any work explaining what causes it?

 Experiment Topology:
Sender --50Mbps-- Router --10--Mbps-- Router --50Mbps-- Receiver
Link one-way delays: 10ms
Initial RTT: about 60ms
BDP = 10 Mbps(*10^6) * 0.06s/ ( 8 * 1000) kB = 75kB

Thank you.
Ahmed

[Li, Ye]

Hi, 

I might have encountered a similar issue as yours. From my investigation, it seems to be due to BBR's round-based bandwidth estimation (https://tools.ietf.org/id/draft-cheng-iccrg-delivery-rate-estimation-00.html). Basically, it records the amount of delivered data in m_nextRoundDelivered when sending data,  and then compares it with those in TcpTxItem corresponding to the ACKed data, so as to approximately determine the end of a round as well as the amount of delivered data in the last round. There might be a dilemma here if the propagation time (RTprop) is high and/or the link is lossy (due to random loss or AQM drops). If the SndBufSize is not large enough, the link is starved and then the bandwidth is obviously underestimated, leading to a reduced throughput. On the other hand, if the buffer is very large, then packet loss may occur due to the bursty traffic (even paced) crossing the default AQM (FqColDel). This may also result in instantaneous underestimated bandwidth because some data is not delivered (lost). Due to the long RTprop, the low estimation may last for a long time and hence the maximum bandwidth estimation is lowered. Overall, my experience is that ns-3's BBR over links with long RTprop is poor (and even worse if there are random packet losses).

These are not rigorously verified though. Just for your reference. It might be helpful to print out the estimated (max) bandwidth in your experiment to further verify. Hope it helps.

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/35899c66-5d09-410c-810b-f79887bbc555n%40googlegroups.com.

--

LI, Ye

School of Information Science and Technology

Nantong University

Nantong 226019, Jiangsu Province, China

GitHub: https://github.com/yeliqseu

[gerd alliu]

I am experiencing the exact same problem with BBR in ns-3. I also tried lower values for the link delay (1ms for instance), and did not observe any changes in behavior. I also tried making the queue smaller than BDP, and I always get this strange behavior for queue size less than 2BDP.

Looking at the states of BBR (based on logs) I observe that BBR's stagnation in throughput corresponds to the ProbeRTT state, i.e. the state is entered after the initial climb so as to drain queues, but this state is never exited. Perhaps this helps somehow..