[quicwg/base-drafts] Processing buffered packets can cause hugely inflated RTT measurements (#3980)

ianswett <notifications@github.com> Mon, 03 August 2020 14:50 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 84FD83A0B0D for <quic-issues@ietfa.amsl.com>; Mon, 3 Aug 2020 07:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level:
X-Spam-Status: No, score=-1.201 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, 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 WcFRakzFAwSM for <quic-issues@ietfa.amsl.com>; Mon, 3 Aug 2020 07:50:47 -0700 (PDT)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615AA3A0B17 for <quic-issues@ietf.org>; Mon, 3 Aug 2020 07:50:47 -0700 (PDT)
Received: from github-lowworker-0f7e7fd.ash1-iad.github.net (github-lowworker-0f7e7fd.ash1-iad.github.net [10.56.110.17]) by smtp.github.com (Postfix) with ESMTP id 58004520E5D for <quic-issues@ietf.org>; Mon, 3 Aug 2020 07:50:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1596466246; bh=F0uadD2vcmhxFERICzLI4PIETCWBkOkRM7bRAcdPUEo=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=i5QV/oas6xr+N5PkcmGAgtLGSZtzsGM37vJIN3dUl9FxLWFr0pJct6B+ZST1wutOl etRjh6hIr0/iMamrdWuFfWWZA0nf51qNNsbQIap/2zaQ8rGHQewsZw4j4SzADPHmTl I1ixFr3yJ1h1BfrSv3QX5JO6owNCr3zO5Cgjt9BM=
Date: Mon, 03 Aug 2020 07:50:46 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5LPC57SJZZS6Z2ZSF5GQCUNEVBNHHCQD7LPA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3980@github.com>
Subject: [quicwg/base-drafts] Processing buffered packets can cause hugely inflated RTT measurements (#3980)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f282446487b3_483516f8138694"; 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-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/rm0lOosrpqntzdb2KQkvSlQcaRk>
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: Mon, 03 Aug 2020 14:50:49 -0000

I'm splitting this from #3821 because the set of changes are disjoint from the current PR for that issue and I think having both issues in one is making it harder to follow. (The rest of this text is an edit of my last post on that issue).


The issue is that ACKs for Handshake and 1-RTT packets could be delayed because the peer doesn't have the keys(either because it takes time to derive them, or it's missing crypto data to derive the next key).

The first RTT sample in Handshake and 1-RTT packet spaces could have substantial delay in excess of the 'no ack delay' in Handshake or max_ack_delay for 1-RTT, which inflates SRTT and RTTVar.

If there's no loss, this fixes itself without harm, which is nice. And it's not as bad for ApplicationData, since that will have a non-0 max_ack_delay, which may be enough to absorb the endpoint delay generating keys or doing cert verification, though it won't typically be enough to adjust for a packet being lost and the data being PTO'd and then that making keys available.

In #3921, Jana's suggested changing ack_delay to including the time packets were buffered as well as and ignoring max_ack_delay for the first sample in a PN space.  I think this is a sensible mitigation, though it doesn't guarantee the issue will not occur.

If no Initial ACKs have been received and the ACK with the large ack_delay is the first ACK of the connection, then you still can't use ack_delay.

The one change we've found mitigates this issue entirely is coalescing packets from the next PN space(Handshake or 1RTT) and then processing the full coalesced packet before processing all buffered packets and sending an ACK. That ensures there's one new packet being acknowledged and you get a non-delayed RTT sample. It doesn't seem onerous to add a "SHOULD process all packets in the current datagram and all buffered packets before sending an ACK to avoid generating multiple inflated RTT samples" to me?

-- 
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/3980