Re: New Version Notification for draft-huitema-quic-ts-05.txt

[Vidhi Goel <[e-mail]>]

Thanks Christian.

I have some comments.

1. Abstract - QUIC is not used as an acronym.

2. Introduction: 
 An example would be the Low Extra Delay Background Transport (LEDBAT)
   [RFC6817 <https://tools.ietf.org/html/rfc6817>] which uses variations in transmission delay ….

I think you meant to say queuing delay here.

3. Introduction:
Using 1WD solves these
   issues.  Similar argument can be made for most delay-based
   algorithms.

I disagree that it can be said for most delay based CCAs. LEDBAT++ and Receive LEDBAT don’t use OWD.
For delay based algorithms, I am of the opinion that we should consider RTT (instead of 1WD) as we should also be mindful of the ACK traffic on the return path, if it is congested and we can do that by slowing down the sender. 

4. Section 2.1
2 or 3 MUST NOT send these frames if the other
   peer does not announce advertise

Typo  - either announce or advertise

5. Section 2.2

Following successful sending negotiation…

“Sending” is probably extraneous here.

6. Section 2.2
 They MAY be sent either before or after the ACK frame.

I think replacing “sent” with “added” would be better here. 

7. Section 2.3
For congestion control, TIMESTAMP frames are treated like ACK frames.

I don’t understand why this should be the case. I think TIMESTAMP frame should be guarded by CC limits.

8. Section 2.3
The same applies to packets
   containing only TIMESTAMP frames

For my curiosity, when do you think packets containing only TS frame would be useful? Also, based on Section 2.6, such a packet wouldn’t be used for 1wd computation.
Is it better to prohibit such a packet?

9. Section 2.6
 latest_1wd = timestamp - send_time_of_largest_acked - phase_shift

I think ack_delay should also be subtracted to remove the processing delay from the 1wd.

Alternatively, one could change how timestamp is encoded. The current text in Section 2.3 says 

"The timestamp encodes the number of microseconds since the beginning
   of the epoch, as measured by the peer at the time at which the packet
   is sent.” 

This could be changed to “time at which the packet was received by the peer”. That would eliminate the processing delay.


Thats all for now. Will let you know if something else comes to mind.

Thanks
Vidhi

> On Mar 17, 2021, at 6:14 PM, Christian Huitema <[e-mail]> wrote:
> 
> This revision of the timestamp draft addresses recent comments by Dmitri Tikhonov, Martin Thomson and Ian Swett. As I mentioned during the IETF meeting, this draft is implemented in picoquic and lsquic, and we have demonstrated interoperability. I would like to see it adopted by the working group.
> 
> -- Christian Huitema
> 
> 
> 
> -------- Forwarded Message --------
> Subject:	New Version Notification for draft-huitema-quic-ts-05.txt
> Date:	Wed, 17 Mar 2021 18:06:55 -0700
> From:	[e-mail] <mailto:[e-mail]>
> To:	Christian Huitema <[e-mail]> <mailto:[e-mail]>
> 
> 
> A new version of I-D, draft-huitema-quic-ts-05.txt
> has been successfully submitted by Christian Huitema and posted to the
> IETF repository.
> 
> Name: draft-huitema-quic-ts
> Revision: 05
> Title: Quic Timestamps For Measuring One-Way Delays
> Document date: 2021-03-17
> Group: Individual Submission
> Pages: 10
> URL: https://www.ietf.org/archive/id/draft-huitema-quic-ts-05.txt <https://www.ietf.org/archive/id/draft-huitema-quic-ts-05.txt>
> Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/ <https://datatracker.ietf.org/doc/draft-huitema-quic-ts/>
> Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts <https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts>
> Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-05 <https://tools.ietf.org/html/draft-huitema-quic-ts-05>
> Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-ts-05 <https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-ts-05>
> 
> Abstract:
> The TIMESTAMP frame can be added to Quic packets when one way delay
> measurements are useful. The timestamp is set to the number of
> microseconds from the beginning of the node's epoch to the time at
> which the packet is sent. The draft defines the "enable_timestamp"
> transport parameter for negotiating the use of this extension frame,
> and the TIMESTAMP 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
> 
>