--- Begin Message ---
Thanks very much for this response. I need to dig in a bit more for sure.
iperf 2 will give every UDP packet's OWD (if the clocks are sync'd) and
will also provide TCP write to read latencies, both supported in histogram
forms. So that's raw samples so to speak. I'm hooking
Keep It Simple, Stupid.
That's a classic architectural principle that still applies. Unfortunately
folks who only think hardware want to add features to hardware, but don't study
the actual real world version of the problem.
IMO, and it's based on 50 years of experience in network and
I will tell you flat out that the arrival time distribution assumption made by
Little's Lemma that allows "estimation of queue depth" is totally unreasonable
on ANY Internet in practice.
The assumption is a Poisson Arrival Process. In reality, traffic arrivals in
real internet applications
> On 8 Jul, 2021, at 4:29 pm, Matt Mathis via Bloat
> wrote:
>
> That said, it is also true that multi-stream BBR behavior is quite
> complicated and needs more queue space than single stream. This complicates
> the story around the traditional workaround of using multiple streams to
>
Hi Matt,
On 08.07.21 at 15:29 Matt Mathis wrote:
I think there is something missing from your model. I just scanned
your paper and noticed that you made no mention of rounding errors,
nor some details around the drain phase timing, The
implementation guarantees that the actual average
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
Hi Matt,
On 08.07.21 at 00:38 Matt Mathis wrote:
Actually BBR does have a window based backup, which normally only
comes into play during load spikes and at very short RTTs. It
defaults to 2*minRTT*maxBW, which is twice the steady state window in
it's normal paced mode.
So yes, BBR
--- Begin Message ---
On Thu, Jul 8, 2021 at 7:25 AM Bless, Roland (TM)
wrote:
> It seems that in BBRv2 there are many more mechanisms present
> that try to control the amount of inflight data more tightly and the new
> "cap"
> is at 1.25 BDP.
>
To clarify, the BBRv2 cwnd cap is not 1.25*BDP. If
--- Begin Message ---
I think there is something missing from your model.I just scanned your
paper and noticed that you made no mention of rounding errors, nor some
details around the drain phase timing, The implementation guarantees that
the actual average rate across the combined BW probe