>>> 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 >> >> <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."
AccECN / L4S can definitely help on the reverse path but only if an implementation supports it. For the near future, we still need to address it and I think RTT helps with that. - Vidhi > On Mar 17, 2021, at 11:03 PM, Vidhi Goel > <[email protected]> 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). > >>> 2. Introduction: >>> An example would be the Low Extra Delay Background Transport (LEDBAT) >>> [RFC6817 <https://tools.ietf.org/html/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.” > > >>> 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 >> >> <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." > >>> 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? > > > Thanks, > Vidhi > >> On Mar 17, 2021, at 9:39 PM, Christian Huitema <[email protected] >> <mailto:[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 >>> <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 >> >> <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 >> >> >
