Date: Tue, 07 Apr 2020 20:09:19 -0700
From: stormlin <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJKZDQ6HZGEU3ZAFHPKV4TEQV7EVBNHHCHCTWCE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3567@github.com>
Subject: [quicwg/base-drafts] Should QUIC provides PING interface for upper
 layer? (#3567)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5e8d405f639ca_43083f994bccd96c34604e1";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Mtj_ijvUmDIn_9wC6SVfrBYBqnY>


----==_mimepart_5e8d405f639ca_43083f994bccd96c34604e1
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

As we know, HTTP/2 provides PING frame and corresponding PING acks, to fetch the application-layer delay. But HTTP/3 states "PING frames do not exist, since QUIC provides equivalent functionality", while QUIC only sends a PING frame to check the reachability of its peer without delay calculation.

The other way of fetching QUIC-layer delay is extracting from the congestion control module. But the application can only read dealy info when there is some data to send. It can not send a probe proactively. 

Should QUIC provides a similar interface to fetch such a application-delay?

-- 
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/3567
----==_mimepart_5e8d405f639ca_43083f994bccd96c34604e1
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p></p>
<p>As we know, HTTP/2 provides PING frame and corresponding PING acks, to fetch the application-layer delay. But HTTP/3 states "PING frames do not exist, since QUIC provides equivalent functionality", while QUIC only sends a PING frame to check the reachability of its peer without delay calculation.</p>
<p>The other way of fetching QUIC-layer delay is extracting from the congestion control module. But the application can only read dealy info when there is some data to send. It can not send a probe proactively.</p>
<p>Should QUIC provides a similar interface to fetch such a application-delay?</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/issues/3567">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJKZL4L7ZEXA75BCE6PTRLPTF7ANCNFSM4MDTAF3A">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AFTOJKZPZ442MNLEZNV235DRLPTF7A5CNFSM4MDTAF3KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4I4KOYIQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/3567",
"url": "https://github.com/quicwg/base-drafts/issues/3567",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5e8d405f639ca_43083f994bccd96c34604e1--