From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 E1F6E3BA8E for ; Tue, 27 Nov 2018 15:58:30 -0500 (EST) Received: by mail-qk1-x735.google.com with SMTP id r71so15482506qkr.10 for ; Tue, 27 Nov 2018 12:58:30 -0800 (PST) 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=9GAHXRvAYHz53mVk8mmn/TA7Pn0qZ+4dwWlKNESeAtY=; b=egNd131H5ZTP/g2REsfiYpwpgwd4gfAxtVJTLnMEB/VQbbyRyVenF7NLDgdoEKHVjD 1/O7LFwhaOExPa/MUOzCL7y23a2aJDz3nf56Un5lv/dSMw6sVr37hk5k3B0/1ZNURSps xaPWmWxI0v2jexL6qzhgXCv52dUnx4IlbGWXOs/LA7ymjmrX3DsJM/8TBoO46+M4fEq4 RXBlZi3Y4vpDBbIEsVHboGxrQJjHYDiX7ztR19wX98H97s1/Uv9pHL/jJVk+DsJ7g18V DFTybUu5ce5fKO4JcEwvhl874v8XNkz8uK9p0A1bmHuysUiF5nlvwthHVAaLhPtzz6tg TpDA== 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=9GAHXRvAYHz53mVk8mmn/TA7Pn0qZ+4dwWlKNESeAtY=; b=Wd3noycycrjjeGkszKEOBymQHARYd6uAzxDc+mp6PrC/IlNFzeI4D7Jn3NUXY8F76J /nL449HJDwXoHxAoxrnOIVV8cmQAxFYOTWraPnLu6y7InnC+q+4+ko+pJu1Zdr4Q8dxU 9C5GWiJ8xJ39UpZf7vUjwkDTZQZu59EeOGLeOQprMAbufOUqDrPxOtRziaHtqvsVcF6P UH1aKuzS3lGsozjtFQ2t4VaAUElBsLXQHDi/osFWSnKH+FSxdzvDARqLPYCZ92EOUghV X6RcZIr0l+4tKptw2rdXemeRAH+9Ez4Hmppxnrz+QRCM+TuFXOGR46GU7gsJsCB9kVbD Z1AQ== X-Gm-Message-State: AA+aEWbZcEhPZste+vIjv27SBWW2H3mL1XOvcBoaVaEpt8rpxtRVA2Lt YRAKsCMIzT+yi0xIBLsQJMGrIo93Uuzy8RP6OaQ= X-Google-Smtp-Source: AFSGD/WBVYtLa/oPZSikRKXXJvc7J4YKunaTtuP7pEVUDoAnfAxH8MULTOArLGdOa/u5XfacbGF7KloLYRmtY9PVtjI= X-Received: by 2002:a37:4f8a:: with SMTP id d132mr30803356qkb.17.1543352310256; Tue, 27 Nov 2018 12:58:30 -0800 (PST) MIME-Version: 1.0 References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> In-Reply-To: From: Dave Taht Date: Tue, 27 Nov 2018 12:58:18 -0800 Message-ID: To: Luca MUSCARIELLO Cc: Jonathan Morton , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] when does the CoDel part of fq_codel help in the real world? 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, 27 Nov 2018 20:58:31 -0000 OK, wow, this conversation got long. and I'm still 20 messages behind. Two points, and I'm going to go back to work, and maybe I'll try to summarize a table of the competing viewpoints, as there's far more than BDP of discussion here, and what we need is sqrt(bdp) to deal with all the different conversational flows. := ) On Tue, Nov 27, 2018 at 1:24 AM Luca Muscariello wrote: > > I think that this is a very good comment to the discussion at the defense= about the comparison between > SFQ with longest queue drop and FQ_Codel. > > A congestion controlled protocol such as TCP or others, including QUIC, L= EDBAT and so on > need at least the BDP in the transmission queue to get full link efficien= cy, i.e. the queue never empties out. no, I think it needs a BDP in flight. I think some of the confusion here is that your TCP stack needs to keep around a BDP in order to deal with retransmits, but that lives in another set of buffers entirely. > This gives rule of thumbs to size buffers which is also very practical an= d thanks to flow isolation becomes very accurate. > > Which is: > > 1) find a way to keep the number of backlogged flows at a reasonable valu= e. > This largely depends on the minimum fair rate an application may need in = the long term. > We discussed a little bit of available mechanisms to achieve that in the = literature. > > 2) fix the largest RTT you want to serve at full utilization and size the= buffer using BDP * N_backlogged. > Or the other way round: check how much memory you can use > in the router/line card/device and for a fixed N, compute the largest RTT= you can serve at full utilization. My own take on the whole BDP argument is that *so long as the flows in that BDP are thoroughly mixed* you win. > > 3) there is still some memory to dimension for sparse flows in addition t= o that, but this is not based on BDP. > It is just enough to compute the total utilization of sparse flows and us= e the same simple model Toke has used > to compute the (de)prioritization probability. > > This procedure would allow to size FQ_codel but also SFQ. > It would be interesting to compare the two under this buffer sizing. > It would also be interesting to compare another mechanism that we have me= ntioned during the defense > which is AFD + a sparse flow queue. Which is, BTW, already available in C= isco nexus switches for data centres. > > I think that the the codel part would still provide the ECN feature, that= all the others cannot have. > However the others, the last one especially can be implemented in silicon= with reasonable cost. > > > > > > On Mon 26 Nov 2018 at 22:30, Jonathan Morton wrot= e: >> >> > On 26 Nov, 2018, at 9:08 pm, Pete Heist wrote: >> > >> > So I just thought to continue the discussion- when does the CoDel part= of fq_codel actually help in the real world? >> >> Fundamentally, without Codel the only limits on the congestion window wo= uld be when the sender or receiver hit configured or calculated rwnd and cw= nd limits (the rwnd is visible on the wire and usually chosen to be large e= nough to be a non-factor), or when the queue overflows. Large windows requ= ire buffer memory in both sender and receiver, increasing costs on the send= er in particular (who typically has many flows to manage per machine). >> >> Queue overflow tends to result in burst loss and head-of-line blocking i= n the receiver, which is visible to the user as a pause and subsequent jump= in the progress of their download, accompanied by a major fluctuation in t= he estimated time to completion. The lost packets also consume capacity up= stream of the bottleneck which does not contribute to application throughpu= t. These effects are independent of whether overflow dropping occurs at th= e head or tail of the bottleneck queue, though recovery occurs more quickly= (and fewer packets might be lost) if dropping occurs from the head of the = queue. >> >> From a pure throughput-efficiency standpoint, Codel allows using ECN for= congestion signalling instead of packet loss, potentially eliminating pack= et loss and associated lead-of-line blocking entirely. Even without ECN, t= he actual cwnd is kept near the minimum necessary to satisfy the BDP of the= path, reducing memory requirements and significantly shortening the recove= ry time of each loss cycle, to the point where the end-user may not notice = that delivery is not perfectly smooth, and implementing accurate completion= time estimators is considerably simplified. >> >> An important use-case is where two sequential bottlenecks exist on the p= ath, the upstream one being only slightly higher capacity but lacking any q= ueue management at all. This is presently common in cases where home CPE i= mplements inbound shaping on a generic ISP last-mile link. In that case, w= ithout Codel running on the second bottleneck, traffic would collect in the= first bottleneck's queue as well, greatly reducing the beneficial effects = of FQ implemented on the second bottleneck. In this topology, the overall = effect is inter-flow as well as intra-flow. >> >> The combination of Codel with FQ is done in such a way that a separate i= nstance of Codel is implemented for each flow. This means that congestion = signals are only sent to flows that require them, and non-saturating flows = are unmolested. This makes the combination synergistic, where each compone= nt offers an improvement to the behaviour of the other. >> >> - Jonathan Morton >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > _______________________________________________ > 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