<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Matt and Jamshid,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 04.07.20 at 19:29 Matt Mathis via
Bloat wrote:<br>
</div>
<p>
<blockquote type="cite">Key takeaway: pacing is inevitable,
because it saves large content providers money (more
efficient use of the most expensive silicon in the data center,
the switch buffer memory), however to use pacing we walk away
from 30 years of experience with TCP self clock, which is the
foundation of all of our CC research....</blockquote>
</p>
<p>Thanks for the interesting read. I have a few comments:</p>
<ul>
<li>IMO, many of the mentioned problems are related to using
packet loss as congestion signal rather than self-clocking.<br>
<br>
</li>
<li>In principle, one can keep utilization high and queuing delay
low with a congestion window based and ACK-clock <br>
driven approach (see TCP LoLa
<a class="moz-txt-link-freetext" href="https://ieeexplore.ieee.org/document/8109356">https://ieeexplore.ieee.org/document/8109356</a>). However, it
currently lacks <br>
heuristics to deal with stretch/aggregated ACKs, but I think one
can extend this like already done in BBR.<br>
<br>
</li>
<li>Pacing is really useful and I think it is important to keep
sending in case the ACK-clock is distorted<br>
by the mentioned problems, but only for a limited time. If one's
estimate for the correct sending rate <br>
is too high, the amount of inflight data increases over time,
which leads to queuing delay and/or loss. <br>
So having the inflight cap as in BBRv1 is also an important
safety measure.<br>
<br>
</li>
<li>"The maximum receive rate is probed by sending at 125% of
max_BW .<br>
If the network is already full and flows have reached their fair
share,<br>
the observed max_BW won’t change."<br>
This assumption isn't true if several flows are present at the
bottleneck.<br>
If a flow sends with 1.25*max_BW on the saturated link, <b>the
observed</b><b><br>
</b><b>max_BW will change</b> (unless all flows are probing at
the same<br>
time) because the probing flow preempts other flows, thereby<br>
reducing their current share. Together with the applied
max-filter<br>
this is the reason why BBRv1 is constantly overestimating the
available<br>
capacity and thus persistently increasing the amount inflight
data <br>
until the inflight cap is hit. The math is in [32] (section 3)
of your<br>
references. Luckily BBRv2 has much more safeguards built-in.<br>
<br>
</li>
<li>"The lower queue occupancy indicates that it is not generally
taking <br>
capacity away from other transport protocols..."<br>
I think that this indication is not very robust, e.g., it may
hold in case <br>
there isn't significant packet loss observed. Observing an
overall<br>
lower buffer occupancy does not necessarily tell you something
about<br>
the individual flow shares. In BBRv1 you could have starving
Cubic <br>
flows, because they were backing-off due to loss, while BBR kept
<br>
sending. <br>
<br>
</li>
<li>Last but not least, even BBR requires an ACK stream as<br>
feedback in order to estimate the delivery rate. But it is
actually<br>
not self-clocked and keeps sending "blindly" for a while. This
is<br>
quite useful to deal with the mentioned stretch/aggregated ACKs,
<br>
if done with care.<br>
</li>
</ul>
<p>Regards,<br>
Roland</p>
<p><br>
</p>
</body>
</html>