HI Christian, Thanks for sharing the idea. I don't profess to be a CC guru but the I-D and the discussion made me wonder something. Now that you decoupled the timestamp from ACK, how coupled are the remaining elements? There's a frame with a field where the value is unilaterally set, some calculations based on the values, and some choices about how to pack.
TIMESTAMP reminds me a little of DATAGRAM. So my curve ball thought is that one could define a container frame for the transport layer signalling that is unreliable and not flow or congestion controlled. We solve the problem once. Then different use cases, like 1WD, could just define a parameter in a container, along with some tips on how/when to packetize it. I can predict some downsides with that approach but curious if others think that make QUIC more pluggable. Cheers Lucas On Thu, 18 Mar 2021, 04:40 Christian Huitema, <[email protected]> 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 > > >
