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

[Christian Huitema <[e-mail]>]

Thanks for the review, Vidhi.

A few comments in line.

On 3/17/2021 8:44 PM, Vidhi Goel wrote:
> Thanks Christian.
>
> I have some comments.
>
> 1. Abstract - QUIC is not used as an acronym.
Yes. I don't use it as an acronym either. But I realize I wrote "Quic" 
instead of "QUIC". I wonder whether WG members have strong feelings 
about that.
>
> 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.
No. I do mean transmission delay, because that's what the LEDBAT 
implementations use. There is an assumption that the variations of 
transmission delays correspond to variations of queuing delays, but 
that's just an hypothesis.
>
> 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.

Well, I am on the opinion that LEDBAT++ should use one-way-delay when 
timestamps are available. It does fallback to RTT when timestamps are 
not available, but that's a fallback mechanism, not a design goal. In 
fact, section 4.5 of the LEDBAT++ draft 
(https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5) 
acknowledges that using RTT instead of one-way-delays "can lead to 
unnecessary slowdowns". The text in that section goes on explaining how 
they mitigate that, but using one-way-delays would definitely be cleaner 
than relying on mitigations.

And yes, it is worth monitoring congestion on the return path, but the 
proper response there is not to "do as if the direct path was 
congested." Other mechanisms are available, such as sending fewer ACKs 
or fewer data on that path.


>
> 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
Yes. Will fix that in the next iteration.
>
> 5. Section 2.2
>
> Following successful sending negotiation…
>
> “Sending” is probably extraneous here.
Yes. Will fix that too.
>
> 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.
Yes.
>
> 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.

This text is based on a suggestion by Ian Swett, `The draft says 
"TIME_STAMP frames are not ack-eliciting. Their loss does not require 
retransmission." I (Ian)  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 (Ian) believe 
treating it like an ACK frame is the ideal option, personally.`

The whole point of adoption by the WG is that we can discuss this issue 
in the WG.

> 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?

I would rather not introduce another failure condition. I have at least 
one use case, measuring one way delays on seldom used paths in a 
multi-path configuration. It is not exactly compelling, but at the same 
time there is no strong reason to prohibit it.

>
> 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.

Good point.  I think the computation should mention the ACK delay.

I like the timestamp being exactly the time at which the packet is sent, 
because that keeps the specification very clean. It also helps scenarios 
in which the timestamp is used with something else than an ACK -- 
challenge response comes to mind, but there are probably other 
possibilities when composing timestamps with other frames. Maybe 
composing timestamps and datagrams in real time applications.

> Thats all for now. Will let you know if something else comes to mind.
>
Thanks for the feedback!

-- Christian Huitema