IETF Logo Mail Archive

Re: [quicwg/base-drafts] Simplify the client's PTO code by allowing the server to send a PING (#3161)

ianswett <notifications@github.com> Tue, 29 October 2019 20:22 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.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 9D11C12001E for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 13:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.382
X-Spam-Level:
X-Spam-Status: No, score=-1.382 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, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 I6r8Ic7g6pyy for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 13:22:58 -0700 (PDT)
Received: from o11.sgmail.github.com (o11.sgmail.github.com [167.89.101.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4762F1208F2 for <quic-issues@ietf.org>; Tue, 29 Oct 2019 13:22:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; 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=oQN72jLiZQLIPVRFNVe2agAEGsQ=; b=mV53/n7j+3OIMqdS BBR5B89JRttddI1ZsfGG6jMDW3SUaq5hiP+zlPleEMhw73aw5E8qMtWSS3gg/s/i NtEnE4D457Klan1n8jl+/QttlrQHQZxQIvidnNq4ECpADG7ifK5u81jgbw5GOFZu BM0lycf6fXyUrrnaoQ+7jYdpEFY=
Received: by filter0801p1iad2.sendgrid.net with SMTP id filter0801p1iad2-3131-5DB89FA0-15 2019-10-29 20:22:56.168004389 +0000 UTC m=+354238.767292940
Received: from github-lowworker-56fcc46.va3-iad.github.net (unknown [140.82.115.15]) by ismtpd0012p1iad1.sendgrid.net (SG) with ESMTP id y7PONeWmTSGKynitsG09pQ for <quic-issues@ietf.org>; Tue, 29 Oct 2019 20:22:56.091 +0000 (UTC)
Received: from github.com (localhost [127.0.0.1]) by github-lowworker-56fcc46.va3-iad.github.net (Postfix) with ESMTP id EBE845E0029 for <quic-issues@ietf.org>; Tue, 29 Oct 2019 13:22:55 -0700 (PDT)
Date: Tue, 29 Oct 2019 20:22:57 +0000
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7W6IS4I4HRK322TEF3YXQC7EVBNHHB5GVBRY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3161/547612280@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3161@github.com>
References: <quicwg/base-drafts/issues/3161@github.com>
Subject: Re: [quicwg/base-drafts] Simplify the client's PTO code by allowing the server to send a PING (#3161)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db89f9fea76d_64443fcab66cd96c2265ba"; 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
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2v9tPzpsdTFkzQwTUYIIuCNUaOM0919jHIZL CpXmx/0Ma6AlRpWyWdYcp7KmYE15dugZuLTgO3vxFzx/MpUgT3gi+yic/gsgmnmO5gnAv4t91ApOU4 flMwrZ80JUcQ2Z5OCfe2Asb4IGCGgMUykBxLADouSToNQDDxl9Wufdr2nA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/ZoTOH25f-Ye3ldsoLdSU6TkfDNs>
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, 29 Oct 2019 20:23:00 -0000

My concern is that the current anti-deadlock mechanism is fairly awkward and rarely needed, which makes me concerned it will be incorrectly implemented.  By sending a PING only packet, the server is essentially informing the client it has something to send, but can't send it due to the amplification limit.

The deadlock happens when the client's Initial is acknowledged, but the client doesn't receive the server's Initial, so it can't decrypt any handshake packets.  In this state, the client has nothing to send.  It can happen even if the server's first flight fits into 3 packets.  But it's expected that typically servers will bundle their ACK of the client's Initial with the server Initial, and this will be rare in practice.

-- 
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/3161#issuecomment-547612280

v2.23.0 | Report a Bug | By Email