Re: [quicwg/base-drafts] Reset min_rtt on persistent congestion (#3927)

Praveen Balasubramanian <notifications@github.com> Wed, 22 July 2020 01:04 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 9A09C3A0744 for <quic-issues@ietfa.amsl.com>; Tue, 21 Jul 2020 18:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level:
X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 9eJq1hc2HA8L for <quic-issues@ietfa.amsl.com>; Tue, 21 Jul 2020 18:04:01 -0700 (PDT)
Received: from out-26.smtp.github.com (out-26.smtp.github.com [192.30.252.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5266F3A0743 for <quic-issues@ietf.org>; Tue, 21 Jul 2020 18:04:01 -0700 (PDT)
Received: from github-lowworker-0f78100.ash1-iad.github.net (github-lowworker-0f78100.ash1-iad.github.net [10.56.25.48]) by smtp.github.com (Postfix) with ESMTP id 8A708280F16 for <quic-issues@ietf.org>; Tue, 21 Jul 2020 18:04:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1595379840; bh=OlHKMdtVaBJuw3BZWM7Tg2ajh+n1NW0LKNvdH+mymog=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=CePeu6h6M03vNcELQl9bpfRcpm62VVJDB71Yk++QdLiKANP6LZUQs2BjnZmJK1BbR AmE4CeITjPCsFyP7O5Ii1trdFkZlMFB2DIT5Vg3lkWQbHxSHdYZXUYqZ2nF6lmSZpk DhtcbO6Yy6BvUrwW/rG4lg1fhpsfufB9Yb6xRP3w=
Date: Tue, 21 Jul 2020 18:04:00 -0700
From: Praveen Balasubramanian <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK46CR6OF3VKYUO5XWV5ENYYBEVBNHHCPCHN7U@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3927/662182651@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3927@github.com>
References: <quicwg/base-drafts/issues/3927@github.com>
Subject: Re: [quicwg/base-drafts] Reset min_rtt on persistent congestion (#3927)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f1790807bbfa_51213fe6098cd96013955"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: pravb
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/kCqkooAULyeJMtFlYqBaOpuBjUg>
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: Wed, 22 Jul 2020 01:04:03 -0000

min_rtt is currently only used for filtering unexpectedly large ack_delay's reported by the peer. If the path RTT truly inflates then the peer will be able to report much larger ack_delay values and get a much lower RTT sample accepted. But I don't think this is a security problem in practice. The only other consideration is that in future QUIC implementations may reuse this computed value for other purposes like delay based congestion control. It's hard to make a judgement call on how important it is to reset min_rtt. I guess I'd be happy with a SHOULD but I can live with a MAY.

-- 
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/3927#issuecomment-662182651