[Cerowrt-devel] [Bloat] DC behaviors today

Luca Muscariello luca.muscariello at gmail.com
Tue Dec 12 10:09:36 EST 2017

I think everything is about response time, even throughput.

If we compare the time to transmit a single packet from A to B, including
propagation delay, transmission delay and queuing delay,
to the time to move a much larger amount of data from A to B we use
throughput in this second case because it is a normalized
quantity w.r.t. response time (bytes over delivery time). For a single
transmission we tend to use latency.
But in the end response time is what matters.

Also, even instantaneous throughput is well defined only for a time scale
which has to be much larger than the min RTT (propagation +  transmission
Agree also that looking at video, latency and latency budgets are better
quantities than throughput. At least more accurate.

On Fri, Dec 8, 2017 at 8:05 AM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> On Mon, 4 Dec 2017, dpreed at reed.com wrote:
> I suggest we stop talking about throughput, which has been the mistaken
>> idea about networking for 30-40 years.
> We need to talk both about latency and speed. Yes, speed is talked about
> too much (relative to RTT), but it's not irrelevant.
> Speed of light in fiber means RTT is approx 1ms per 100km, so from
> Stockholm to SFO my RTT is never going to be significantly below 85ms
> (8625km great circle). It's current twice that.
> So we just have to accept that some services will never be deliverable
> across the wider Internet, but have to be deployed closer to the customer
> (as per your examples, some need 1ms RTT to work well), and we need lower
> access latency and lower queuing delay. So yes, agreed.
> However, I am not going to concede that speed is "mistaken idea about
> networking". No amount of smarter queuing is going to fix the problem if I
> don't have enough throughput available to me that I need for my application.
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20171212/00f63b3c/attachment-0001.html>

More information about the Cerowrt-devel mailing list