Re: [quicwg/base-drafts] Persistent Congestion Time Threshold (#2365)

ianswett <> Wed, 30 January 2019 12:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 706D31295D8 for <>; Wed, 30 Jan 2019 04:38:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aqmbt360oJMp for <>; Wed, 30 Jan 2019 04:38:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 718241294FA for <>; Wed, 30 Jan 2019 04:38:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=nvF2e+HRJqOxLBaPHOLjzzcJRa4=; b=YlqUkmFgwGBB+PjX QDfnyW7KDQcbBQl6iLrs96JDJDKI7GPZfO8V48aWvRN23FM9B017euBsUDJPodTO 713AXzynBlfoutQtKZ6+BKFSlEv8QD9gQ7fPp7nhGbak2c5B6zqf7WUxCZ36xUP7 nfrCaQ7difl/HgWcfAZtxPJp4WE=
Received: by with SMTP id filter1055p1las1-13803-5C519ABA-28 2019-01-30 12:38:18.536462953 +0000 UTC m=+125002.524514820
Received: from (unknown []) by (SG) with ESMTP id hJEZDIc5QLuBmbmEDgohZQ for <>; Wed, 30 Jan 2019 12:38:18.389 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id 5216080274 for <>; Wed, 30 Jan 2019 04:38:18 -0800 (PST)
Date: Wed, 30 Jan 2019 12:38:18 +0000
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2365/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Persistent Congestion Time Threshold (#2365)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c519aba4eb7c_5c823ff7e16d45c074367"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2IEiV5ZBOE5vHcF+/PLhh5TwexfWwl+/CLN7 /Ds4MfAuCp9tAbfUJ+skSnln4eE6ZHQnCbeBy/Vb12sUZGvYBKUjC4bFVL9qJKiMhswDWQJ20/KzQ4 SUt+QILDZg4bjv0Ffy1rDgZ/RxrapUbRMJg5cxJAM/xZkUaOCz3hyMzZ97bkd9gVfjhTmjnXwdB4Hc o=
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jan 2019 12:38:22 -0000

ianswett commented on this pull request.

>  When an ACK frame is received that establishes loss of all in-flight packets
-sent prior to a threshold number of consecutive PTOs (pto_count is more than
-kPersistentCongestionThreshold, see {{cc-consts-of-interest}}), the network is
-considered to be experiencing persistent congestion, and the sender's congestion
-window MUST be reduced to the minimum congestion window (kMinimumWindow).  This
-response of collapsing the congestion window on persistent congestion is
-functionally similar to a sender's response on a Retransmission Timeout (RTO) in
-TCP {{RFC5681}}.
+sent over a long enough period of time, the network is considered to be
+experiencing persistent congestion.  Commonly, this can be established by
+consecutive PTOs, but since the PTO timer is reset when a new ack-eliciting
+packet is sent, an explicit duration must be used to account for those cases
+where PTOs do not occur or are substantially delayed.  This duration is the
+equivalent of kPersistentCongestionThreshold consecutive PTOS, smoothed_rtt +
+4 * rttvar + max_ack_delay * ((2 ^ kPersistentCongestionThreshold) - 1).

Q for here and below: Should max_ack_delay be added after exponential backoff, instead of before?  Adding it after incentivizes implementations to indicate a realistic value, since an unrealistic one just adds to rttvar, which seems desirable.

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