[quicwg/base-drafts] When to reduce cwnd in recovery (#4050)

mirjak <notifications@github.com> Tue, 25 August 2020 09:34 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B71E63A0BD4 for <quic-issues@ietfa.amsl.com>; Tue, 25 Aug 2020 02:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id D7wCSiPK5Thk for <quic-issues@ietfa.amsl.com>; Tue, 25 Aug 2020 02:34:17 -0700 (PDT)
Received: from out-14.smtp.github.com (out-14.smtp.github.com []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEE03A0BD0 for <quic-issues@ietf.org>; Tue, 25 Aug 2020 02:34:17 -0700 (PDT)
Received: from github-lowworker-45eca55.ac4-iad.github.net (github-lowworker-45eca55.ac4-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id AA18D7A0D73 for <quic-issues@ietf.org>; Tue, 25 Aug 2020 02:34:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1598348056; bh=sDSdPphG39uzHCeLdB+HLqckbUaJq6KmAZUlmarVXo8=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=yIPVQgjr55+pivcst9cjbWfU8gpM6yNcgy7EZqO4RSq3KVE05IAJS6N4ce91BObYC vohjwQFP3vbg3Cl6ZnEt9RsoS8/SWc4NZNc51oTT/qpe+lRqkt8ULTPTq/wY9hBtaW z7+3ciqyf8X9bYfntSKPEu/D9Ii9S/kdKyPy1hYE=
Date: Tue, 25 Aug 2020 02:34:16 -0700
From: mirjak <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3GL6GK6WDLEEN6VEV5KC6BREVBNHHCRWKM7A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4050@github.com>
Subject: [quicwg/base-drafts] When to reduce cwnd in recovery (#4050)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f44db1864da5_2d7d1964564566"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mirjak
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/2uCc-sBs40pZrtDWFmvv1fZqdNk>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2020 09:34:19 -0000

The recovery draft currently has the following text:

When slow start is exited, the congestion
window halves and the slow start threshold is set to the new congestion

However, in https://tools.ietf.org/html/rfc5681#section-4.3 ssthresh is reduced upon entering recovery but cwnd is set to ssthresh when leaving recovery.

There is more discussion on this already in PR #3978 and PR #4005.

@ianswett proposed by email the following alternative wording:

MUST reduce the CWND to the ssthresh by the time recovery is exited and implementations MAY use a variety of mechanisms to reduce bytes in flight, including reducing it immediately, packet conservation, PRR(RFC6937) or decreasing the pacing rate.

@janaiyengar noted this text from RFC5861 which works as well:

   Second, until all lost segments in the window of data in question are
   repaired, the number of segments transmitted in each RTT MUST be no
   more than half the number of outstanding segments when the loss was

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: