From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 E3C7F3CB35; Fri, 2 Jul 2021 16:29:02 -0400 (EDT) Received: by mail-lj1-x234.google.com with SMTP id p24so14991821ljj.1; Fri, 02 Jul 2021 13:29:02 -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=nU6iiagGVarDYnzRJOxeuXeA8hNfQZOM35PMTLczQKk=; b=iPjD31sWwmIwgii73FkT08VK4BSIuYcYyWyVsXw+cbDZ6eRajxpn6bSSyQUCkBIBHt CMjVXHpGPBbE2+JMPdtFQNH/bLss536Aih2kP+cQJABfKthb3P/cetHE5Nr7W9oFXnbo AlKqU0QUehfOa8GUwl+VjZU5MnnZH3g7/Rt2AC6vX40GX1rGkJtzJSooBQA/7V5EqwB7 YOwY+bNxJcH7sR6DdsOPEqDPn0F17oX/hEquGSiohsjuOzVeVQC0G3kwzvVSqjqBnsUq 1wrNg61Vkfuga1uNScKODI3NK7zEBMK4Jmd1ZA10GzzUOx34cnbYJjnb8qK3E/KBiPgN yrcw== 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=nU6iiagGVarDYnzRJOxeuXeA8hNfQZOM35PMTLczQKk=; b=pOHeBPGf+B+68dzxuwFMNJz8BhUT//MJF6fsmLXg39cHakNtNit2yXwO5jn9gFRpjl tZmyyHlUI0O/Ap6S/qn8wfLskNwZX+AruGbm2Vm19hsmhusx2P7H2KFuPB8lAPxXM/Rl Yq95nHGoEYrcXNLw0nm2XuhD0Vjl7x5ENmLcz2vjzWzjs7QBhGOB1KiMfH4PcyNjAJ8W QW75PspXW4f8P/WStVxBVK5TRf/P+6qbAtSQRSuuzCkhLBDghNtAR+bgPtmpNBDxG8d/ bFKSoGQbXHNFaIAkdniUpuW85CCY8XGGBq6ASCp0tbfTyEdClLHJAighKhTkPrDVGyc9 /uaw== X-Gm-Message-State: AOAM530EYI8mdClR5ExY5LZ/Qer0ysczcJ1Sa9FS6QAOXDfLYQOtDmlY Gk5AtiJYgRgKAnJpKRmFEvc= X-Google-Smtp-Source: ABdhPJyiUBLwHOgiBXmjgrvzUl+qaIfqo4F2vJvUIn4tl0JzpV0QlHhr7xKKeI4O65ujdkGl1puxMA== X-Received: by 2002:a2e:4c19:: with SMTP id z25mr963040lja.47.1625257741572; Fri, 02 Jul 2021 13:29:01 -0700 (PDT) Received: from jonathartonsmbp.lan (37-136-219-147.rev.dnainternet.fi. [37.136.219.147]) by smtp.gmail.com with ESMTPSA id q4sm465109ljh.13.2021.07.02.13.28.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jul 2021 13:29:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jonathan Morton In-Reply-To: <20210702095924.0427b579@hermes.local> Date: Fri, 2 Jul 2021 23:28:52 +0300 Cc: Dave Taht , David Reed , bloat , Ketan Kulkarni , "cerowrt-devel@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: <5DAEFFA0-8ACF-413E-89F7-22D34CEB4EBB@gmail.com> References: <55fdf513-9c54-bea9-1f53-fe2c5229d7ba@eggo.org> <871t4as1h9.fsf@toke.dk> <3D32F19B-5DEA-48AD-97E7-D043C4EAEC51@gmail.com> <1465267957.902610235@apps.rackspace.com> <20210702095924.0427b579@hermes.local> To: Stephen Hemminger X-Mailer: Apple Mail (2.3445.9.7) Subject: Re: [Bloat] Bechtolschiem 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: Fri, 02 Jul 2021 20:29:03 -0000 > On 2 Jul, 2021, at 7:59 pm, Stephen Hemminger = wrote: >=20 > In real world tests, TCP Cubic will consume any buffer it sees at a > congested link. Maybe that is what they mean by capture effect. First, I'll note that what they call "small buffer" corresponds to about = a tenth of a millisecond at the port's link rate. This would be = ludicrously small at Internet scale, but is actually reasonable for = datacentre conditions where RTTs are often in the microseconds. Assuming the effect as described is real, it ultimately stems from a = burst of traffic from a particular flow arriving at a queue that is = *already* full. Such bursts are expected from ack-clocked flows coming = out of application-limited mode (ie. on completion of a disk read), in = slow-start, or recovering from earlier losses. It is also possible for = a heavily coalesced ack to abruptly open the receive and congestion = windows and trigger a send burst. These bursts occur much less in paced = flows, because the object of pacing is to avoid bursts. The queue is full because tail drop upon queue overflow is the only = congestion signal provided by the switch, and ack-clocked = capacity-seeking transports naturally keep the queue as full as they can = - especially under high statistical multiplexing conditions where a = single multiplicative decrease event does not greatly reduce the total = traffic demand. CUBIC arguably spends more time with the queue very = close to full than Reno does, due to the plateau designed into it, but = at these very short RTTs I would not be surprised if CUBIC is equivalent = to Reno in practice. The solution is to keep some normally-unused space in the queue for = bursts of traffic to use occasionally. This is most naturally done = using ECN applied by some AQM algorithm, or the AQM can pre-emptively = and selectively drop packets in Not-ECT flows. And because the AQM is = more likely to mark or drop packets from flows that occupy more link = time or queue capacity, it has a natural equalising effect between = flows. Applying ECN requires some Layer 3 awareness in the switch, which might = not be practical. A simple alternative it to drop packets instead. = Single packet losses are easily recovered from by retransmission after = approximately one RTT. There are also emerging techniques for applying = congestion signals at Layer 2, which can be converted into ECN signals = at some convenient point downstream. However it is achieved, the point is that keeping the *standing* queue = down to some fraction of the total queue depth reserves space for = accommodating those bursts which are expected occasionally in normal = traffic. Because those bursts are not lost, the flows experiencing them = are not disadvantaged and the so-called "capture effect" will not occur. - Jonathan Morton=