From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 929713B29E for ; Thu, 1 Nov 2018 10:20:48 -0400 (EDT) Received: by mail-qt1-x82e.google.com with SMTP id z2-v6so21278878qts.1 for ; Thu, 01 Nov 2018 07:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7vLdUqnS7xIqVt/4tuDTfeQk0GGP0P2V640PxAf6hhM=; b=fIF+/g4SJKVuNgE+BjJQuwdM4sa8whaRy1yxX2h6ED/U0EDJrqvJFiLnH3FORKqaR9 m2uzIAoLv1E3pDnSpnYlki46G+BUh2MsXWtJXWuDW4U+6nvuq2Jezt8JrLEkORY1++qH 8yRUVpYc2rAUsk00hbm0aC2Gr8e9DVv550Jaz1FazEbXlpwXnpLnAgIi04BcwJiD8Nc4 Fg8orbZO/RKuCP3JpixnyoCDYE9TQHhQDWgdALg7il6lsKGAmYwAYNoudhXbmIwX4Thy urX7hMBzPme34MGBBpiP3QtEyk4bPH3RbGXUMc+j0SLF0Qt8x6nGXvxCkCok1tkIHGsR tJ6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7vLdUqnS7xIqVt/4tuDTfeQk0GGP0P2V640PxAf6hhM=; b=rlsyBcUSyf2H73cN788KzM0mdaYBPD77MKBUAAG3gltuE0spZ7qBDDJaG+9fTZICHM ZtJz174kE5mGFqeiTJmzPxXK93t3JBbhLOSNxybAoPiVppajRqK26JSt8I2EXaK/bF5/ ICY5APhz+tNJKUrZ1zuyaYqZX31VG/WL87fOBJcXHMlGBwVc+B07QAqgFpd64pls5aAC SY4RsIgdsxIuBmdNgOVruWnZMnf1y1VBc5zRck3gcxSx3kyR7Wq+lRpGXKXHNk7h0NZa wsUx3KZSQdMxvHtNzZ4ha8stkLq+9AOCxF1bPfpkm4DtK3vwD13j7B+YnErKzcnJ0Ar8 LstA== X-Gm-Message-State: AGRZ1gLd+JA2IRe0P09RDcCa184Pc5i0QWMOMSEomNA7nIUqRQwijpgy thImQzmN2P8rBWjzH8oIP4wtwMseY95SWa8jXyg= X-Google-Smtp-Source: AJdET5d9nKCvmreXZ7yirin9Vw6CFpmyR/+pdiVTMIDGPNn6KfLAhZ35eVwwTHcIC4dcAmz3cTcpXUFIf3C3AqMEdoI= X-Received: by 2002:ac8:2e44:: with SMTP id s4mr6981675qta.355.1541082047974; Thu, 01 Nov 2018 07:20:47 -0700 (PDT) MIME-Version: 1.0 References: <878t2h1jtm.fsf@taht.net> In-Reply-To: From: Dave Taht Date: Thu, 1 Nov 2018 07:20:34 -0700 Message-ID: To: Michael Welzl Cc: =?UTF-8?Q?Dave_T=C3=A4ht?= , tsvwg@ietf.org, bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] 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: Thu, 01 Nov 2018 14:20:48 -0000 On Thu, Nov 1, 2018 at 3:39 AM Michael Welzl wrote: > > Hi, > > > > On 29 Oct 2018, at 05:02, Dave Taht wrote: > > > > > > > Dear Greg: > > > > I don't feel like commenting much on ietf matters these days > > but, jeeze, > > (snip) > > There seems to me to be a disconnect here, the core of which is this comm= ent: > > > > Did I rant already that the vast majority of flows are non-saturating? > > That's a bug, not a feature - and you seem to treat it as an unchangeable= fact. It's been the case for 50 years. Until we have one sole source of data (which given industry consolidation is seemingly increasingly likely), coming from one big machine (unlikely). The original cablelabs (2012?) study of this stuff assumed that growth of a web page would be past 6MB by now, it instead is under 3. > Despite the undebatable importance of bufferbloat and its impact on e2e p= acket latency, this is only one of the factors playing into the "latency" t= hat 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? In my mind QUIC, when basically nailed up, with its improvements to tcp (0-rtt crypto, pacing, bbr) is in the end game here, and "if only" fq existed on the cmts's as I'd had so much hope for after the arris study bufferbloat would be basically be over and dealt with. And most flows would still be short. > Flow completion time has to do with saturation as well. FCT was not a subject of that draft. My (admittedly ranty) points were: * Mis-representation of how fq_codel actually worked for political purposes= , in particular mischaracterizing the behavior for videoconferencing over more typical links... * a complaint that despite all the work on bufferbloat, measured CMTS buffering was still in the 680ms range at 100mbit. If anyone had bothered to click on the pfsense discussion, I "subtly" pointed at a FIOS measurement of 120ms... Still waiting for that first step from the US cable industry. Things are getting MUCH better in the past 2 years (see http://www.dslreports.com/speedtest/results/bufferbloat ) just not (if you scroll down) in the US. I don't, incidentally, know why they are getting better... certainly I have some good numbers on the size of the wifi deployment... * Pointing out that sch_cake did diffserv, per host and per flow fq, and docsis framing. Some of which had applicability to the draft. We have not the slightest intent to bring that to the ietf, but it does tackle and solve what little there was of a "collision" problem, thoroughly... the diffserv stuff might help (I routinely give dns a boost)... feel free to go reflash a router and see if it helps in your scenarios. Inbound shaping is cpu intensive, but it works pretty well. > > Cheers, > Michael > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740