Re: [quicwg/base-drafts] Persistent Congestion Requires Probes to be Sent (#2356)
Nick Banks <notifications@github.com> Tue, 22 January 2019 20:32 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68016131089 for <quic-issues@ietfa.amsl.com>; Tue, 22 Jan 2019 12:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
X-Spam-Status: No, score=-12.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_HI=-5, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkGYBmDGw8w5 for <quic-issues@ietfa.amsl.com>; Tue, 22 Jan 2019 12:32:18 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C64131083 for <quic-issues@ietf.org>; Tue, 22 Jan 2019 12:32:18 -0800 (PST)
Date: Tue, 22 Jan 2019 12:32:17 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1548189137; bh=zQ+7fLe1ZXHnKxZZSzh73wjH7PQziSKvjMOz39O7zXY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZtVNqHVsv6PwpRvUhd9tHn9Jv0LWDhjjToivEKWZ++jfffCcqx3ylEJz36Lqxs03O Akkms8QqhXwxI/lYSXk899v9zJOOxj3vxG8FPgnHyzCm4zN7z0IV+lyswCfQEBp6mM HmQZMbNVaZ1dXo9SJ3TU5YVE/HbU6WmOmqFGdaQs=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab2eaeb8d564abbabebe253242ba697d6f2f0d56f292cf00000001185f3fd192a169ce17f3a0d1@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2356/456552366@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2356@github.com>
References: <quicwg/base-drafts/issues/2356@github.com>
Subject: Re: [quicwg/base-drafts] Persistent Congestion Requires Probes to be Sent (#2356)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c477dd14a1eb_286d3fb9c74d45c0522941"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/zXkgq1bfFfVoCEiZqat1NRaBgYs>
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, 22 Jan 2019 20:32:20 -0000
Fundamentally, I think we should separate persistent congestion determination from how many (if any) probes were actually sent. Persistent congestion is just an amount of time (since the oldest outstanding, retransmittable packet) we should wait before declaring "something really bad is going on" for this connection, and back off. In good (non-edge) cases, the current logic works well and is fairly simple to implement. It just breaks down in the cases where any other traffic is getting periodically sent. I would propose just making a separate timer/timeout for persistent congestion. It would follow similar rules for RTO for TCP: 1. When a new packet is sent, if the PC (persistent congestion) timer isn't running, start it. 2. When you receive an ACK that acknowledged new data, restart the timer. The next question is just how long to run the timer. Assuming we want to keep the current values (sum of 3 PTOs), I think it'd be something like: `(smoothed_rtt + 4 * rttvar + max_ack_delay) * ((2 ^ 3) - 1)` If this sounds reasonable, I can attempt to put together a PR. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/quicwg/base-drafts/issues/2356#issuecomment-456552366