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 delays)
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@swm.pp.se> wrote:
On Mon, 4 Dec 2017, dpreed@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@swm.pp.se
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat