IETF Logo Mail Archive

Re: [quicwg/base-drafts] PTO after handshake completion is not well-defined (#3831)

Kazuho Oku <notifications@github.com> Wed, 08 July 2020 09:45 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 2CAFB3A0CE6 for <quic-issues@ietfa.amsl.com>; Wed, 8 Jul 2020 02:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Level:
X-Spam-Status: No, score=-1.483 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_24=1.618, 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 tc_EoFydn7yr for <quic-issues@ietfa.amsl.com>; Wed, 8 Jul 2020 02:45:45 -0700 (PDT)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44693A0CE2 for <quic-issues@ietf.org>; Wed, 8 Jul 2020 02:45:44 -0700 (PDT)
Received: from github-lowworker-0eea13f.ash1-iad.github.net (github-lowworker-0eea13f.ash1-iad.github.net [10.56.109.26]) by smtp.github.com (Postfix) with ESMTP id E00508C07B0 for <quic-issues@ietf.org>; Wed, 8 Jul 2020 02:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1594201543; bh=rq5vQ7n6wM38+j5BHSHVmMN4S4IRcS/rFlJCaPj09v8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=kgtmwhKImQXfDIwSwG2zCGB5HIjd924lwi26v+3d/c5yRP4mA9V+P2DbCYKAsnqi5 22ucAPOVpm1R/nutwyAcrFT8yWFhv62pdabbvW6y/q25uGrW0QeHwgo8dnT/q/PjhL JCv0kVvFZQzXzMj5N639B1GVkB0TLCHwOzO8rKn4=
Date: Wed, 08 Jul 2020 02:45:43 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZYC2YAJZXPQR77E4V5CF3MPEVBNHHCNXO66A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3831/655413052@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3831@github.com>
References: <quicwg/base-drafts/issues/3831@github.com>
Subject: Re: [quicwg/base-drafts] PTO after handshake completion is not well-defined (#3831)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f0595c7d005d_3fa53f852a6cd95c2708a5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/SWP5eLFRkF6Pa9eA0Y4ld4GCi68>
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, 08 Jul 2020 09:45:46 -0000

Discussed the issue offline, @marten-seemann and I think that there is a strong example that does not involve multiple PN spaces. Consider the following case:
* endpoint sends Initial
* after 1 second, endpoint sends Initial (PTO)
* after 1ms, the endpoint receives an ACK for Initial (PTO)

At this point, the endpoint would declare persistent congestion because the duration of congestion (1 seconds) is greater than the threshold (i.e. `(smoothed_rtt + 4 * rttvar + max_ack_delay) * kPersistentCongestionThreshold` where smoothed_rtt is 1ms, rttvar is 1ms, and max_ack_delay is zero).

The problem is that determining persistent congestion based on SRTT is not a good idea until the RTT estimate becomes stable.

I think the easiest fix (which is beneficial at this late stage) would be to disable persistent congestion until the handshake concludes.

-- 
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/3831#issuecomment-655413052

v2.39.1 | Report a Bug | By Email | System Status