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

Christian Huitema <> Tue, 29 October 2019 19:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42E09120168 for <>; Tue, 29 Oct 2019 12:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.454
X-Spam-Status: No, score=-6.454 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_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e5AzW7ENOcGF for <>; Tue, 29 Oct 2019 12:25:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B76311200A3 for <>; Tue, 29 Oct 2019 12:25:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C86796E14C3 for <>; Tue, 29 Oct 2019 12:25:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572377139; bh=3dsQzvyqk2WzKLBleZraio8X+xXS2duYDXaFnbB6qQ4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZzZt3lcqldGR7/uvp5mdW0N5R/oBJK9BAFSjm83XBKnEvq7RG/9aYiVchTjXALH4r ifIjmLPgor+2OWfvDSRK+My+vDlkW1MPKP2WIBkP2MBQvkHl68o8L62+IRMMsgMjYN 0QCdZPYmPqj9nDRQ2gsfogIfb2gBfUEV0W6jJrOQ=
Date: Tue, 29 Oct 2019 12:25:39 -0700
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3161/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
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_5db89233b909d_78223fd0832cd95c1060b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Oct 2019 19:25:43 -0000

Isn't this concern why we designed the Retry mechanism in the first place? If we are concerned about address spoofing attacks, the simple solution might be to generalize retry. As in, "if the server can predict that its first flight will contain more than 3 times the amount of data received with the client's Initial packets, then it SHOULD verify the source address using Retry."

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: