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
