From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 B57C83BA8E for ; Tue, 12 Jun 2018 02:39:10 -0400 (EDT) Received: by mail-qk0-x230.google.com with SMTP id g14-v6so14452981qkm.6 for ; Mon, 11 Jun 2018 23:39:10 -0700 (PDT) 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:content-transfer-encoding; bh=QEB3R5fm8JlF2RdBQKYkIHhCS3aiKutZo4MzfQRrGG8=; b=OEtqkChrPDKeSIHdR4HfHf4OvzSdEyDRLtPWOM/bN8Y1NxVYSC3JRrB2eRTIDOCFfM cUBoWr067/m7lzeYDUCm/WqBPHuN+f1JFdJE3qoOGtm90WdVPwz50DEaRJ+B/KakWLTk GnGYAcK1H/aBX1ZIGN6bm89VgAB6eW7EW5Aun3CjMn0Qy2k11jeNrvb+fSQqT9vaB9Pm KIwVYmCw9+3cRymOkecFueCS1lcxpsEYtk37os/1WTni035uggvezWlCQsuylPrTeox8 YiJaptW0GqS5ixHA3y3UjOtFGzv6MT78kK1ek/z+D57FULFDvOXStmuavVT2geU5nbZ2 3yBw== 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:content-transfer-encoding; bh=QEB3R5fm8JlF2RdBQKYkIHhCS3aiKutZo4MzfQRrGG8=; b=ozj8QEY0bd6iuwix0bPxWwaHSL5RrwBydpBSKCfrxiz2U31xyABFq1XqdlZUtQBlka O1bSiA7u5grwrHp9oEuNBm+3AsK1RO+00RSLumclm0vjOv18e5pVW/cCiW77O+Z9Qv5z pTivnm90Sfq3OBIpawC1U6FvFki2f5ANnFWoC9ZENtu5emkPfl+q8A24BQzRjcgmHurE UUwhvxLlRXKx+FFY6ZDVrP56JleqNFJ+agcfP6Wf3pcTW8zFqlyPI87oJZZxzV/MHenm smZUiKh0h0dT+MDTKYWwoK1ixQaQNU90oHotWjhlgxBNdMyMSeFTfKISRn1A+ivQpxId 98ZA== X-Gm-Message-State: APt69E2baJY9H4VczMEITRusm+/XQCOVsNCYEpwec6ewywtxdcM342x0 1UikDfk/uo/2tCCn7RlU1FcmZiDSnFjCeXIaqQk= X-Google-Smtp-Source: ADUXVKLG0CxChkrWXGQjqSRqYhyWW+DJA0gYApfplS4EGXVCOpJWbCAY4Y5tcqNx72VzHyBtWogFg0u8H8d0RZEqRjA= X-Received: by 2002:a37:646:: with SMTP id 67-v6mr2046257qkg.35.1528785550214; Mon, 11 Jun 2018 23:39:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 23:39:09 -0700 (PDT) In-Reply-To: <3E669490-800E-40AE-B172-A99CB615822F@gmail.com> References: <152717340941.28154.812883711295847116.malone@soybean.canonical.com> <4f67f9b3-05a1-8d15-0aee-dfe8ea730d7c@gmail.com> <73c25a21-0ace-b5ee-090e-d06fb3b8dc60@kit.edu> <3F65061F-4F05-4F3F-8A43-FFCC1D27F585@gmail.com> <61E48C91-AEF9-4FF4-9F83-45EC7148EC54@jonathanfoulkes.com> <9675C88A-FCC0-43EB-9C71-CBEFD67408CB@gmx.de> <6AD85E99-BCD8-4548-AAA4-F5B08599C7AD@gmail.com> <36BE9775-A306-4DA3-B2D9-430FF07E391C@gmx.de> <3E669490-800E-40AE-B172-A99CB615822F@gmail.com> From: Dave Taht Date: Mon, 11 Jun 2018 23:39:09 -0700 Message-ID: To: Jonathan Morton Cc: Sebastian Moeller , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking 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: Tue, 12 Jun 2018 06:39:10 -0000 "So there is no effect on other flows' latency, only subsequent packets in the same flow - and the flow is always hurt by dropping packets, rather than marking them." Disagree. The flow being dropped from will reduce its rate in an rtt, reducing the latency impact on other flows. I regard an ideal queue length as 1 packet or aggregate, as "showing" all flows the closest thing to the real path rtt. You want to store packets in the path, not buffers. ecn has mass. It is trivial to demonstrate an ecn marked flow starving out a non-ecn flow, at low rates. On Wed, Jun 6, 2018 at 6:04 AM, Jonathan Morton wro= te: >>>> The rationale for that decision still is valid, at low bandwidth every= opportunity to send a packet matters=E2=80=A6 >>> >>> Yes, which is why the DRR++ algorithm is used to carefully choose which= flow to send a packet from. >> >> Well, but look at it that way, the longer the traversal path after the c= ake instance the higher the probability that the packet gets dropped by a l= ater hop. > > That's only true in case Cake is not at the bottleneck, in which case it = will only have a transient queue and AQM will disengage anyway. (This assu= mes you're using an ack-clocked protocol, which TCP is.) > >>>> =E2=80=A6and every packet being transferred will increase the queued p= ackets delay by its serialization delay. >>> >>> This is trivially true, but has no effect whatsoever on inter-flow indu= ced latency, only intra-flow delay, which is already managed adequately wel= l by an ECN-aware sender. >> >> I am not sure that I am getting your point=E2=80=A6 > > Evidently. You've been following Cake development for how long, now? Th= is is basic stuff. > >> =E2=80=A6at 0.5Mbps every full-MTU packet will hog the line foe 20+ mill= iseconds, so all other flows will incur at least that 20+ ms additional lat= ency, this is independent of inter- or intra-flow perspective, no?. > > At the point where the AQM drop decision is made, Cake (and fq_codel) has= already decided which flow to service. On a bulk flow, most packets are th= e same size (a full MTU), and even if the packet delivered is the last one = presently in the queue, probably another one will arrive by the time it is = next serviced - so the effect of the *flow's* presence remains even into th= e foreseeable future. > > So there is no effect on other flows' latency, only subsequent packets in= the same flow - and the flow is always hurt by dropping packets, rather th= an marking them. > > - Jonathan Morton > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619