New version of the Time Stamp draft. I have been using Time Stamps in
Picoquic for some time, in particular in my implementation of HyStart,
because measuring one way delays avoid "early exit from HyStart" errors
due to transient queues on the return path. Time Stamps are also very
useful when managing data recovery for multipath, as explained in
https://huitema.wordpress.com/2021/01/27/estimating-round-trip-and-one-way-delays-in-multipath-quic-sessions/.
Is the working group ready to consider adopting this draft?
-- Christian Huitema
-------- Forwarded Message --------
Subject: New Version Notification for draft-huitema-quic-ts-04.txt
Date: Mon, 01 Feb 2021 18:07:11 -0800
From: [email protected]
To: Christian Huitema <[email protected]>
A new version of I-D, draft-huitema-quic-ts-04.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.
Name: draft-huitema-quic-ts
Revision: 04
Title: Quic Timestamps For Measuring One-Way Delays
Document date: 2021-02-01
Group: Individual Submission
Pages: 9
URL: https://www.ietf.org/archive/id/draft-huitema-quic-ts-04.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/
Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts
Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-04
Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-ts-04
Abstract:
The TIME_STAMP frame can be added to Quic packets when one way delay
measurements is useful. The timestamp is set to the number of
microseconds from the beginning of the connection to the time at
which the packet is sent. The draft defines the "enable_time_stamp"
transport parameter for negotiating the use of this extension frame,
and a new frame types for the time_stamped frame.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
