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

[Christian Huitema]

On 3/17/2021 11:03 PM, Vidhi Goel wrote:
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.
It would be good to be consistent. I’d prefer it to be acronym (QUIC).

The transport specification states clearly:

QUIC: The transport protocol described by this document. QUIC is a name, 
not an acronym.

What you want is using the all capital name "QUIC", rather than my 
deviant spelling "Quic". I personally feel that as QUIC is a name, it 
should be written the way we spell other names like "John" or "Eric". 
But then, all the QUIC drafts use the all-capitals spelling, so I am not 
going to argue too long for this one...


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.

I am confused. RFC 6817 says the below which points to queuing delay varying 
while other delays remaining constant-ish.

“End-to-end delay can be decomposed into transmission (or
    serialization) delay, propagation (or speed-of-light) delay, queueing
    delay, and processing delay.  On any given path, barring some noise,
    all delay components except for queueing delay are constant.  To
    observe an increase in the queueing delay in the network, a LEDBAT
    sender separates the queueing delay component from the rest of the
    end-to-end delay, as described below.”
Again, this is an hypothesis based on theory. Increase in one way delays 
are well correlated with queuing delay, but what is measure is the delay 
from sending the packet to receiving it. I am accustomed to describing 
that as the "transmission delay", but you are right that the term is 
often used as in RFC 6817, to describe the "serialization" delay. 
"End-to-end" delay might be the more appropriate term to describe what 
the nodes actually measure.


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”
Yes, and LEDBAT++ continues to say the below. For a delay based CC, how do you 
suggest the increased delay on reverse path (receiver to sender) be handled, if 
we don’t use RTT?
"but in practice this
    seems to benefit the workloads because bottleneck link can carry ACK
    traffic in the other direction for the competing flows."
This is explaining that they err on the side of caution, which is OK 
because LEDBAT is for low priority traffic anyhow. But if you remove the 
"low priority" property, this is not OK.

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.
Sorry, I am not too familiar with IETF procedures. Does this mean we can 
discuss in the next IETF meeting or something else?

Mailing list, github, interim, IETF... The way we do things.

-- Christian Huitema



On Mar 17, 2021, at 9:39 PM, Christian Huitema <huit...@huitema.net> wrote:

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