Re: [quicwg/base-drafts] Should QUIC provides PING interface for upper layer? (#3567)

David Schinazi <> Thu, 09 April 2020 00:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 105EB3A1A52 for <>; Wed, 8 Apr 2020 17:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.72
X-Spam-Status: No, score=-6.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, 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_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 yYx3pViI8p6M for <>; Wed, 8 Apr 2020 17:10:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 877E63A1A57 for <>; Wed, 8 Apr 2020 17:10:44 -0700 (PDT)
Date: Wed, 08 Apr 2020 17:10:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1586391043; bh=RteJLbZrCcrz9bubom/Z0Fvy91Z4NDL+QElltfXf9DM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=D8vsm8Bt8pswpbpvfk4o1L9g0gzIR7FGxsdtMoK003IKeGxBRP+GKizljKDmPfIkI jJByFU0rqagPzRFQV7rn7/ZRBV4txzwlHvBNQa1SFVoh0E8QgRhEtq3nRDo1nLnMsM r33cqw3bDfWwA0PV792F+kkNFj8KYNbY5g7TwhD4=
From: David Schinazi <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3567/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Should QUIC provides PING interface for upper layer? (#3567)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e8e680365e66_7ae23fef1cecd95c108215"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
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: Thu, 09 Apr 2020 00:10:52 -0000

[HTTP/2 PING frames]( exist to measure the round-trip delay, they're not specific to application-layer delay. QUIC blurs the layers in such a way that I don't think there is an actual difference between application-layer delay and network-layer delay. (Not that the OSI model ever made sense, but that's another conversation...) The combination of QUIC PING and ACK frames allow you to calculate the round-trip delay in a way that's even more accurate because the [ACK frame]( carries  an `ACK Delay` field that allows you to compute on-device delay. Could you clarify what exactly it is that QUIC does not allow to measure today?

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