From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 636273B2A4 for ; Mon, 13 Feb 2023 21:58:52 -0500 (EST) Received: by mail-ej1-x631.google.com with SMTP id dr8so36742952ejc.12 for ; Mon, 13 Feb 2023 18:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ve5wEfI2eCAzndI+EEfMbGJLMRKjVE0e/ui3kgiFrqI=; b=TtBHdJmkXu+TN4XZd8ecwrGxRZbOimk+g89xuLaG0fkWp+BATVVXnniW2W2lMWBB2u uFwtKPHkggsUYiycJkpd9Ig/jM3At7S4+U8AOHjr6/UbPHH+OMmdUwTCV2G2uoEnhLP3 tezcePOLhV4CRCdWt1ixUdriazTTRz0E9JtW83guxux5jz1/bRs+eixjyOWE7vs0ZP9o dkgQacKjghnmPm6+kiQrh1AHsnwnDAxY72Zj+5VbLY7wntbpYBbcqmByBq60ELDYCyRl aoBD2fdBRasVb8fQwjB8OP1PKd7A4xTK1+rOQUMlqbjSgK5taHvEWAo6aWpchI0kVzFn rNKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ve5wEfI2eCAzndI+EEfMbGJLMRKjVE0e/ui3kgiFrqI=; b=o83su5uU+7e9euNeHt7PMamAqtwW7Zh7gPNHhUX2yar3iQalzK8UlJ4XlEv5BEkRYI +vBvYmMR4x0GcCcRuKATnd/rImwigjothk1kAnTrvkbMzE0Q52ViMMdXkFQRIKsn+uVn MYNRYuiMDdSZJs6KDSVZPiFQYVGg0ciJkgnY/5sX+SQ6qXo8liHdQtH0arjyd06tacGc YdcG2PY9yvzDd09t4JA58Smacdoj1pTTA9GSwrEe6Zlfsb6TJDgbF30j6X4aXeCXrutT YLJRW+T9/ygx+lqRMkZr688vjcBueXueJS6vWC+RW+HwgA02xJF7KhyXK+SjGw+L3hKY zodQ== X-Gm-Message-State: AO0yUKUf/ugdwn9u53BdMGMa1lNRWO0o26jsX/eXFKoIiINx/Ydtg4Go jhdSG03py2tlJ/uzng1Vz3w= X-Google-Smtp-Source: AK7set9Get1NYJMtI+f2nQDX0aEoRX3NBenCmWOtUAllKvWFPMM9JJJ/6FZECQU1CGYZjnC5V6Y6nw== X-Received: by 2002:a17:906:ccd1:b0:88b:f26d:7b25 with SMTP id ot17-20020a170906ccd100b0088bf26d7b25mr313418ejb.28.1676343531271; Mon, 13 Feb 2023 18:58:51 -0800 (PST) Received: from smtpclient.apple (37-33-124-64.bb.dnainternet.fi. [37.33.124.64]) by smtp.gmail.com with ESMTPSA id mm15-20020a170906cc4f00b008b130155fd1sm165218ejb.6.2023.02.13.18.58.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Feb 2023 18:58:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Jonathan Morton In-Reply-To: Date: Tue, 14 Feb 2023 04:58:48 +0200 Cc: bloat Content-Transfer-Encoding: quoted-printable Message-Id: <5D54142F-645C-4F92-8A20-1581D1F064EF@gmail.com> References: <20230211144853.BFE4D18C091@mercury.lcs.mit.edu> <5bb4686d-b6b7-62e1-305d-e06e4568c374@3kitty.org> To: Dave Taht X-Mailer: Apple Mail (2.3654.100.0.2.22) Subject: Re: [Bloat] [ih] Installed base momentum (was Re: Design choices in SMTP) 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, 14 Feb 2023 02:58:52 -0000 > ---------- Forwarded message --------- > From: Jack Haverty via Internet-history = >=20 > Even today, as an end user, I can't tell if "congestion control" is > implemented and working well, or if congestion is just mostly being > avoided by deployment of lots of fiber and lots of buffer memory in = all > the switching locations where congestion might be expected. That of > course results in the phenomenon of "buffer bloat". That's another > question for the Historians. Has "Congestion Control" in the Internet > been solved? Or avoided? It's a good question, and one that shows understanding of the underlying = problem. TCP has implemented a workable congestion control system since the = introduction of Reno, and has continued to take congestion control = seriously with the newer flavours of Reno (eg. NewReno, SACK, etc) and = CUBIC. Each of these schemes reacts to congestion *signals* from the = network; they probe gradually for capacity, then back off rapidly when = that capacity is evidently exceeded, repeatedly. Confusingly, this process is called the "congestion avoidance" phase of = TCP, to distinguish it from the "slow start" phase which is, equally = confusingly, a rapid initial probe for path capacity. CUBIC's main = refinement is that it spends more time near the capacity limit thus = found than Reno does, and thus scales better to modern high-capacity = networks at Internet scale. In the simplest and most widespread case, the overflow of a buffer, = resulting in packet loss, results in that loss being interpreted as a = congestion signal, as well as triggering the "reliable stream" function = of retransmission. Congestion signals can also be explicitly encoded by = the network onto IP packets, in the form of ECN, without requiring = packet losses and the consequent retransmissions. My take is that *if* networks focus only on increasing link and buffer = capacity, then they are "avoiding" congestion - a strategy that only = works so long as capacity consistently exceeds load. However, it has = repeatedly been shown in many contexts (not just networking) that = increased capacity *stimulates* increased load; the phenomenon is called = "induced demand". In particular, many TCP-based Internet applications = are "capacity seeking" by nature, and will *immediately* expand to fill = whatever path capacity is made available to them. If this causes the = path latency to exceed about 2 seconds, DNS timeouts can be expected and = the user experience will suffer dramatically. Fortunately, many networks and, more importantly, equipment providers = are now learning the value of implementing AQM (to apply congestion = signals explicitly, before the buffers are full), or failing that, of = sizing the buffers appropriately so that path latency doesn't increase = unreasonably before congestion signals are naturally produced. This = allows TCP's sophisticated congestion control algorithms to work as = intended. - Jonathan Morton