From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 5F5AC3CB39; Fri, 29 Dec 2023 01:38:11 -0500 (EST) Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2ccabfd9762so48247081fa.1; Thu, 28 Dec 2023 22:38:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703831889; x=1704436689; darn=lists.bufferbloat.net; 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=pV/DArDQxh9HKLiQ18gUT5VEEYUN5NMEGU5L+gAO6ss=; b=cvvs/y5Xbya35/iSGNLVZ6Xtmlj4iezWdkTfpoyWauudb5EI+sc3Q7g6rpG0R9OnrG qu1ya/eihDxmjiSNngkW0JyaZkGovYvA9FjuNJXgXaiRKXxejjhzlPmR1FgC+V4Pepja /BYA+TyxbJ+HOaOTzREuPORvMoWEKh5lQKypUSo/jhY/TK3BdkYgtdNuceSh2DykkId+ BDPr7YPh2irFDHgW6sWB1z9LWgKZ6Us5uobV+36J35eC6aDUN526mJNtZKje8zLOEkWz aKTPkJPVYC5I6mTajimD5zSM7KNNRFD0VQsEO8rm4mel785BaXItOc5Qavz0vhGdPWLs kv9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703831889; x=1704436689; 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=pV/DArDQxh9HKLiQ18gUT5VEEYUN5NMEGU5L+gAO6ss=; b=i2s2HVIMyb8FPJz1/cHOvMgJpGzodK9BvI9vhGBaiXyL/lrQMV8BNLOdUnc9+j6YRN qM+du6Jo/lJa909RbOea0HZ9jyuws4j8tvF/yOUkJ0M/4T+U6lW4wzn9QCNfnsYYKfAi 7EQe+OcJwEF0icEsUyogqRSaCSX2dpKU5xckfXRMqDk6lLrUPw6mShZ1HpqSZy0ZW5yb tEIyHPWuUx9JiXPmH7RUuLT5GFNxUruSgLq8SwasvkOAzaKtJ8jp9+ggIEC1J4+x+qa6 TrOXCRwupDurZmW4Ei0H4dEuTOGTajXBspsJP4cIk7K0esUmW/szdArGtsHEISXRowka eYzg== X-Gm-Message-State: AOJu0YzsTOAyZFmSJvI9z0R79IIPCNOZtg8abQETTetT6xKxkfoux5xK jutj1jYYBR4R/sI27zZ0JhA= X-Google-Smtp-Source: AGHT+IE7fp2Kcjfmq61N1n6o5MWa9VTIP/SQu9nuReRjx4SGK1UragUihlGFzVulZu+T/aLYyse4yw== X-Received: by 2002:a05:651c:a06:b0:2cc:bd75:86f1 with SMTP id k6-20020a05651c0a0600b002ccbd7586f1mr4823024ljq.25.1703831888851; Thu, 28 Dec 2023 22:38:08 -0800 (PST) Received: from smtpclient.apple (37-219-218-208.nat.bb.dnainternet.fi. [37.219.218.208]) by smtp.gmail.com with ESMTPSA id l18-20020a2ea812000000b002cc9a9d0cecsm3301661ljq.23.2023.12.28.22.38.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Dec 2023 22:38:08 -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: Fri, 29 Dec 2023 08:38:06 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Dave Taht via Bloat , codel Content-Transfer-Encoding: quoted-printable Message-Id: <02C24B24-0436-461E-B198-8F0B4E7326E3@gmail.com> References: To: Sebastian Moeller X-Mailer: Apple Mail (2.3654.100.0.2.22) Subject: Re: [Bloat] slow start improvement 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, 29 Dec 2023 06:38:11 -0000 > On 28 Dec, 2023, at 12:17 pm, Sebastian Moeller via Bloat = wrote: >=20 > The inherent idea seems to be if one would know the available capacity = one could 'jump' the cwnd immediately to that window... (ignoring the = fact the rwnd typically takes a while to increase accordingly*).=20 Yes, I've just got to the bit about selectively ignoring rwnd - that's a = straight violation of TCP. There may be scope for optimising congestion = control in various ways, but rwnd is a fundamental part of the protocol = that predates congestion control itself; it implements TCP's original = function of "flow control". Sending data outside the rwnd invites the = receiver invoking RST, or even firewall action, which I can guarantee = will have a material impact on flow completion time! Slow-start already increases cwnd to match the BDP in at most 20 RTTs, = and that's the extreme condition, starting from an IW of 1 segment and = ramping up to the maximum possible window of 2^30 bytes (assuming an MSS = of at least 1KB, which is usual). The more recent standard of having = IW=3D10 already shortens that by 3-4 RTTs. It's an exponential process, = so even quite large changes in available bandwidth don't affect the = convergence time very much. TCP's adaptation to changes in the BDP = after slow-start is considerably slower, even with CUBIC. I also note a lack of appreciation as to how HyStart (and HyStart++) = works. Their delay-sensitive criterion is triggered not when the cwnd = exceeds the BDP, but at an earlier point when the packet bursts (issued = at double the natural ack-clocked rate) cause a meaningful amount of = temporary queue delay. This queuing is normally drained almost = immediately after it occurs, *precisely because* the cwnd has not yet = reached the true path BDP. This allows slow-start to transition to = congestion-avoidance smoothly, without a multiplicative-decrease = episode. HyStart++ adds a further phase of exponential growth on a more = cautious schedule, but with essentially the same principle in mind. The irony is that they rely on precisely the same phenomenon of = short-term queuing, but observe it in the form of the limited delivery = rate of a burst, rather than an increase in delay on the later packets = of the burst. - Jonathan Morton=