From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 E673C3CB35 for ; Wed, 3 Apr 2019 06:09:45 -0400 (EDT) Received: by mail-lj1-x22f.google.com with SMTP id y6so14276200ljd.12 for ; Wed, 03 Apr 2019 03:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1DVkzQxoaLulQIlyv3uU/L/lCQyyvNu/mrw/QnE316c=; b=DQ/8UAC4IwVbsYfDoNEYxXN6Vm1XNjYIj9GEiTtGdZBymplsLIBv57Lam0u8SSoP9/ pPu/nxHoPwu98eOCkFXflIQRHg9I8yK21g9phrzQWKpEA1z68CQwADezaNeUx0DkZFuN +RvlRgmZ1G5sOBGWdGCoqGeAZERzo4JNtzY4u/dlj84Urc7h3JHW9y1kT/mZ/fZjdit1 nXpu5m/hXYdJFOQnU0AbSKvJdz9Jzd2gc+fXje1rKpt+FrN84JZa4d8rHo0UY0e2GCOc Mly9hFAbwbTsCYavnOqC8mw4pN3bgDuH4h5VKSU0y/V7bsso8BGPpIGCREmm0XaAEg8d yHQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1DVkzQxoaLulQIlyv3uU/L/lCQyyvNu/mrw/QnE316c=; b=RSkcToLLFfBqfbPCw1stpOJfddBvx3hRfwkL/Owjm8VcquhZ4UIvBAeSZP/T40bJ1v 5HAJ7lezP5A59TeF8Ngy9uLbMxClNYCUzLIfP2qh/18w4xPGCfMpnSlE9B0zcZ3gms+f 76Pb3Mz+OhTwnWy6cTlYNOLmeZSlYMOLaIwM3/FO8cYC+4QyUKKC/qGfB0suzBV4q5Op 7jGgt5GUDWw6UfwXXfw7Q0Bi23zmdb98+eTVV/0glZQHh3vmZNuvZZnZUFgnbN0sGslk gfP0305b+9ny3blmG248zl9+2YLQflgWoMscUwSAxdzoVwSLmmFNJde51t0VAAg0x1Nv WE3w== X-Gm-Message-State: APjAAAVS9VZBTccLHuazFLgiNTjCGZ1ywTMTxSixA8nqtShoQ/6MVDTl nKVjXsZEksfntoRhV9Ie1Gs= X-Google-Smtp-Source: APXvYqxUochy9KeSigo0Hwpfj2uEDxPUoWO/AW2DP6e5u9nAlt3ikIYD6SYTxM8V0a+ahpN9xyEInw== X-Received: by 2002:a2e:4ca:: with SMTP id a71mr37712386ljf.39.1554286184812; Wed, 03 Apr 2019 03:09:44 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-226-9-nat-p.elisa-mobile.fi. [83.245.226.9]) by smtp.gmail.com with ESMTPSA id g95sm3566126ljg.63.2019.04.03.03.09.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 03:09:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Wed, 3 Apr 2019 13:09:42 +0300 Cc: Ryan Mounce , Jonathan Foulkes , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C360DB4-777C-466E-9FC1-0CA8F719F797@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] number of home routers with ingress AQM 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: Wed, 03 Apr 2019 10:09:46 -0000 >> Fact is... ingress shaping is a hack. >=20 > That is harsh, but I give you sub-optimal and approximate As the designer of this particular hack, I would characterise it as a = workaround. It *does* work, within certain assumptions which are = narrower than for a conventional before-the-bottleneck deployment. Cake = includes a specific shaper mode to help expand those constraints = slightly. One of the assumptions is indeed that the flows respond promptly to AQM, = or are non-queue-building in the first place. Without that, the ingress = shaper cannot exercise control over the contents of the dumb bottleneck = queue upstream of it. There is no clear relationship between the fill = levels of the two queues; the dumb one can be full but only trickling = into the smart one downstream. Conventional TCP traffic responds to a CE mark after one RTT and should = clear its excess traffic from the queue well within two (assuming = congestion-avoidance mode); if the AQM also has a response delay built = in (as Codel does), that may result in 3 RTTs between congestion onset = and establishment of control. Slow start is another matter entirely, = but one I haven't analysed very throughly in this context; it's safe to = say however that draining a 2x overshoot will take longer than a = few-segment overshoot. SCE would potentially remove some of that delay, as it signals = immediately a queue appears, but we're still talking about one-plus RTTs = delay before the dumb queue is drained. SCE also pulls the TCP out of = slow-start soon enough to avoid a 2x overshoot (there's an interaction = with sender-side pacing here; without pacing, slow-start is exited very = early). This is the best-case scenario until the true bottleneck learns = AQM. L4S' modification of the response to CE goes in the opposite direction, = unless the AQM is modified to suit. DCTCP stabilises at 2 CEs per RTT = (each CE removes half a segment from the cwnd, while the Reno-linear = growth function adds one segment per RTT). Codel grows its signalling = frequency linearly over time; if its interval is set close to the actual = path RTT (as is recommended), it will take 3 intervals/RTTs to reach the = stability criterion for DCTCP, and a further 3 RTTs to control it all = the way down to the true BDP. This is not too bad in an FQ context, but how long would it take to = correct a 2x overshoot from slow-start? DCTCP doesn't get a halving of = cwnd per RTT until every single packet is CE-marked! I think we need to set up a testbed with the new TCP Prague = implementation to demonstrate these effects. - Jonathan Morton