From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 732FC3CB35 for ; Sun, 4 Nov 2018 13:17:00 -0500 (EST) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gJMxG-0006ji-CE; Sun, 04 Nov 2018 19:16:58 +0100 Received: from dhcp-9c52.meeting.ietf.org ([31.133.156.82]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1gJMxE-000505-R7; Sun, 04 Nov 2018 19:16:58 +0100 From: Michael Welzl Message-Id: <78003B95-6395-4E0A-8908-C8E1221FC2CF@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_A9FDCF4E-D212-4DDD-84B6-8D198CC61761" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 5 Nov 2018 01:16:51 +0700 In-Reply-To: Cc: bloat , tsvwg@ietf.org To: Dave Taht References: <878t2h1jtm.fsf@taht.net> X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 31.133.156.82 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.156.82; envelope-from=michawe@ifi.uio.no; helo=dhcp-9c52.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.021, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 15B412E5F768B33BA36A00355B4C1317665075F4 Subject: Re: [Bloat] [tsvwg] quick review and rant of "Identifying and Handling Non Queue Building Flows in a Bottleneck Link" X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 18:17:00 -0000 --Apple-Mail=_A9FDCF4E-D212-4DDD-84B6-8D198CC61761 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, It seems I overlooked this answer, sorry - some answers below, but also = cutting stuff to keep it to the point: > On Nov 1, 2018, at 9:20 PM, Dave Taht wrote: >> Despite the undebatable importance of bufferbloat and its impact on = e2e packet latency, this is only one of the factors playing into the = "latency" that I perceive when I click on the link as I surf the = Internet. >=20 > Doing a breakdown of that latency - most of that seems solved... >=20 > Background prefetch > DNS lookup > SSL connection negotiation > The actual transfer. > Screen draw.... >=20 > I'm still missing your point. Is looking for "sparseness" part of a > CCN-like effort? No, it=E2=80=99s just about flow completion time (=E2=80=9CThe actual = transfer=E2=80=9D) above being a function not only of the queue length, = but also of the capacity the flow gets to use. Hence the push for a = larger initial window. >> Flow completion time has to do with saturation as well. >=20 > FCT was not a subject of that draft. Right - sorry for side-tracking. > My (admittedly ranty) points were: I read them - I didn=E2=80=99t want to get into this debate, it was only = a side comment about not all flows being limited, and there being some = value in better capacity usage too. Cheers, Michael --Apple-Mail=_A9FDCF4E-D212-4DDD-84B6-8D198CC61761 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

It = seems I overlooked this answer, sorry - some answers below, but also = cutting stuff to keep it to the point:


On Nov 1, 2018, at 9:20 PM, Dave Taht <dave.taht@gmail.com>= wrote:


Despite= the undebatable importance of bufferbloat and its impact on e2e packet = latency, this is only one of the factors playing into the "latency" that = I perceive when I click on the link as I surf the Internet.

Doing a breakdown of that latency - most of that seems = solved...

Background = prefetch
DNS = lookup
SSL = connection negotiation
The actual transfer.
Screen draw....

I'm still missing your point. Is looking for "sparseness" = part of a
CCN-like = effort?

No, = it=E2=80=99s just about flow completion time (=E2=80=9CThe actual = transfer=E2=80=9D) above being a function not only of the queue length, = but also of the capacity the flow gets to use. Hence the push for a = larger initial window.


Flow = completion time has to do with saturation as well.

FCT was not a subject of that draft.

Right - sorry = for side-tracking.


My (admittedly ranty) points = were:

I read = them - I didn=E2=80=99t want to get into this debate, it was only a side = comment about not all flows being limited, and there being some value in = better capacity usage too.

Cheers,
Michael

= --Apple-Mail=_A9FDCF4E-D212-4DDD-84B6-8D198CC61761--