From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F18B13B2A4; Tue, 12 Dec 2017 10:09:35 -0500 (EST) Received: by mail-qt0-x22a.google.com with SMTP id g9so47952860qth.9; Tue, 12 Dec 2017 07:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WdEYewey0JayuXMYUm2K6396iqL5ITKX8YrR6Il76Vg=; b=ZbTR4jnHXjjTUuZK9F+66NypxorsFaiRxaPNJnapXh2UazYFJJ2MMwfmO3Cy+8Fj+Q +bQFLu/U6QEkpOBVD7ZV7aHOOkdZ0SeqBKeqWjCRUhR0EnNoAti02b1Qk6WPBHI75V47 VF/V27eO/HALAjCvB6yBD5XcKRLhjWkWn+6oYlhhUHNM06ALLKo+CDq+HpeaIDKtNqbQ GXwb4ZSqJP3tr6JJ6Xc0wJM3oxoMrlzU/mgCEMm3v9IXBNkc+PbZBGL07NYYXShu1ypv tcTiJRQh2Sjmt5kbuambr9i5AfLc49zEL8BGzBY9EsHSHItj5ripWuPdfO/Qny9TbuME HQzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WdEYewey0JayuXMYUm2K6396iqL5ITKX8YrR6Il76Vg=; b=VgeGDqYtZOOKoXBUd9OxwGP3DKO7GJZkMnXgecGNM4GZan3NJ4A2jzxEI9PAEYgHkr vnn2oJYFzQPzEZzwxAHZTUQ1pqmT8WlFDrgX9tcVUcRlPzDg5gkRWTDSOayeyFq4IqZT mipL/r0x+v90kHOcwENcEK9Vb8IvGRDsD4tO7cORtIHYAAVrqCmSWR25hK9FQuphLhi6 xZtvmOimd6lQB07VxBH6okXDPOZqYvsDjhJtnhgSrtgXZ524tV77oa6xMywO9Tedaysk 6g1K0wMGiWvltNoV4cBId9DtwbGXR4U4Bd4lApBb6jiY0B2oHnajbHWzFYoV6ZoLtoVD 9hbw== X-Gm-Message-State: AKGB3mIGYlDBtnoCoqheRdrfQZQogcQzMNiRoEYysIqghb6xCey0Koe+ 1GmQE4JlYy4+7LqgYMi5yG0TDusj73Pbz4N/4jg= X-Google-Smtp-Source: ACJfBouCdb07WMU0fdbjATAa4MhBxHCsRWqEuSiGss0Dslpb84T93Qqw+ZO4kd7v/ECAEBMLEwFvK0JXjlKNhx9yaHM= X-Received: by 10.55.158.70 with SMTP id h67mr5946180qke.192.1513091375446; Tue, 12 Dec 2017 07:09:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.191.227 with HTTP; Tue, 12 Dec 2017 07:09:34 -0800 (PST) In-Reply-To: References: <92906bd8-7bad-945d-83c8-a2f9598aac2c@lackof.org> <87bmjff7l6.fsf_-_@nemesis.taht.net> <1512417597.091724124@apps.rackspace.com> From: Luca Muscariello Message-ID: To: Mikael Abrahamsson Cc: dpreed@reed.com, "cerowrt-devel@lists.bufferbloat.net" , bloat Content-Type: multipart/alternative; boundary="94eb2c06e34af24115056026090d" X-Mailman-Approved-At: Mon, 30 Mar 2020 07:21:14 -0400 Subject: Re: [Cerowrt-devel] [Bloat] DC behaviors today X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 12 Dec 2017 15:09:36 -0000 X-Original-Date: Tue, 12 Dec 2017 16:09:34 +0100 X-List-Received-Date: Tue, 12 Dec 2017 15:09:36 -0000 --94eb2c06e34af24115056026090d Content-Type: text/plain; charset="UTF-8" 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 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 > --94eb2c06e34af24115056026090d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think everything is about response time, even throughput= .=C2=A0

If we compare the time to transmit a single pack= et 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 t= o B we use throughput in this second case because it is a normalized
<= div>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 through= put is well defined only for a time scale which has to be much larger than = the min RTT (propagation +=C2=A0 transmission delays)
Agree a= lso that looking at video, latency and latency budgets are better quantitie= s than throughput. At least more accurate.










On Fri, Dec 8, 2017 at 8:05 AM, Mikael Abrahamsson <s= wmike@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 ide= a about networking for 30-40 years.

We need to talk both about latency and speed. Yes, speed is talked about to= o much (relative to RTT), but it's not irrelevant.

Speed of light in fiber means RTT is approx 1ms per 100km, so from Stockhol= m 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 acro= ss the wider Internet, but have to be deployed closer to the customer (as p= er 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 ap= plication.

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

--94eb2c06e34af24115056026090d--