Subject: Fwd: New Version Notification for draft-huitema-quic-ts-03.txt

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Aug 2020 22:30:59 -0700

I just posted version 03 of the timestamp draft, applying Dmitri's
suggestion.

-- Christian Huitema

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-huitema-quic-ts-03.txt
Date: 	Mon, 10 Aug 2020 22:27:39 -0700
From: 	[email-masked]
To: 	Christian Huitema <[email-masked]>

A new version of I-D, draft-huitema-quic-ts-03.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-quic-ts
Revision: 03
Title: Quic Timestamps For Measuring One-Way Delays
Document date: 2020-08-10
Group: Individual Submission
Pages: 9
URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-ts-03.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/
Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-03
Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts
Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-ts-03

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

---

From: Ian Swett <[email-masked]>
Date: Tue, 11 Aug 2020 09:40:09 -0400

Thanks for the update Christian.  Two comments on the draft.

1) The draft says "TIME_STAMP frames are not ack-eliciting. Their loss does
not require retransmission." I believe the draft should clarify whether
adding a TIME_STAMP frame to a packet causes it to count as in-flight as
PADDING would, or not in-flight as an ACK frame would. I believe treating
it like an ACK frame is the ideal option, personally.

2) To me, TIMESTAMP and enble_timestamp read much easier than TIME_STAMP
and enable_time_stamp, because timestamp is a single word.

On Tue, Aug 11, 2020 at 1:31 AM Christian Huitema <[email-masked]>
wrote:

> To: Christian Huitema <[email-masked]> <[email-masked]>
>
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Aug 2020 10:59:37 -0700

Thanks, Ian. Noted the comments as an issue in
https://github.com/huitema/quic-1wd/issues/2. Will work on these changes
with the next version.

On 8/11/2020 6:40 AM, Ian Swett wrote:
> 1) The draft says "TIME_STAMP frames are not ack-eliciting. Their loss
> does not require retransmission." I believe the draft should clarify
> whether adding a TIME_STAMP frame to a packet causes it to count as
> in-flight as PADDING would, or not in-flight as an ACK frame would. I
> believe treating it like an ACK frame is the ideal option, personally.
> 2) To me, TIMESTAMP and enble_timestamp read much easier than
> TIME_STAMP and enable_time_stamp, because timestamp is a single word.
>
> On Tue, Aug 11, 2020 at 1:31 AM Christian Huitema <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     From: 	[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>
>
>
>
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>