Hi Matt,
[sorry for the late reply, overlooked this one]
please, see comments inline.
On 02.07.21 at 21:46 Matt Mathis via Bloat wrote:
The argument is absolutely correct for Reno, CUBIC and all
other self-clocked protocols. One of the core assumptions in
Jacobson88, was that the clock for the entire system comes from
packets draining through the bottleneck queue. In this world, the
clock is intrinsically brittle if the buffers are too small. The
drain time needs to be a substantial fraction of the RTT.
I'd like to separate the functions here a bit:
1) "automatic pacing" by ACK clocking
2) congestion-window-based operation
I agree that the automatic pacing generated by the ACK clock (function
1) is increasingly
distorted these days and may consequently cause micro bursts.
This can be mitigated by using paced sending, which I consider very useful.
However, I consider abandoning the (congestion) window-based approaches
with ACK feedback (function 2) as harmful:
a congestion window has an automatic self-stabilizing property since the
ACK feedback reflects
also the queuing delay and the congestion window limits the amount of
inflight data.
In contrast, rate-based senders risk instability: two senders in an
M/D/1 setting, each sender sending with 50%
bottleneck rate in average, both using paced sending at 120% of the
average rate, suffice to cause
instability (queue grows unlimited).
IMHO, two approaches seem to be useful:
a) congestion-window-based operation with paced sending
b) rate-based/paced sending with limiting the amount of inflight data
However, we have reached the point where we need to discard that
requirement. One of the side points of BBR is that in many
environments it is cheaper to burn serving CPU to pace into short
queue networks than it is to "right size" the network queues.
The fundamental problem with the old way is that in some contexts the
buffer memory has to beat Moore's law, because to maintain constant
drain time the memory size and BW both have to scale with the link
(laser) BW.
See the slides I gave at the Stanford Buffer Sizing workshop december
2019: Buffer Sizing: Position Paper
<https://docs.google.com/presentation/d/1VyBlYQJqWvPuGnQpxW4S46asHMmiA-OeMbewxo_r3Cc/edit#slide=id.g791555f04c_0_5>
Thanks for the pointer. I don't quite get the point that the buffer must
have a certain size to keep the ACK clock stable:
in case of an non application-limited sender, a very small buffer
suffices to let the ACK clock
run steady. The large buffers were mainly required for loss-based CCs to
let the standing queue
build up that keeps the bottleneck busy during CWnd reduction after
packet loss, thereby
keeping the (bottleneck link) utilization high.
Regards,
Roland
Note that we are talking about DC and Internet core. At the edge, BW
is low enough where memory is relatively cheap. In some sense BB came
about because memory is too cheap in these environments.
Thanks,
--MM--
The best way to predict the future is to create it. - Alan Kay
We must not tolerate intolerance;
however our response must be carefully measured:
too strong would be hypocritical and risks spiraling out
of control;
too weak risks being mistaken for tacit approval.
On Fri, Jul 2, 2021 at 9:59 AM Stephen Hemminger
<step...@networkplumber.org <mailto:step...@networkplumber.org>> wrote:
On Fri, 2 Jul 2021 09:42:24 -0700
Dave Taht <dave.t...@gmail.com <mailto:dave.t...@gmail.com>> wrote:
> "Debunking Bechtolsheim credibly would get a lot of attention to the
> bufferbloat cause, I suspect." - dpreed
>
> "Why Big Data Needs Big Buffer Switches" -
>
http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf
<http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf>
>
Also, a lot depends on the TCP congestion control algorithm being
used.
They are using NewReno which only researchers use in real life.
Even TCP Cubic has gone through several revisions. In my
experience, the
NS-2 models don't correlate well to real world behavior.
In real world tests, TCP Cubic will consume any buffer it sees at a
congested link. Maybe that is what they mean by capture effect.
There is also a weird oscillation effect with multiple streams,
where one
flow will take the buffer, then see a packet loss and back off, the
other flow will take over the buffer until it sees loss.
_______________________________________________
_______________________________________________
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
