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

[Vidhi Goel <[e-mail]>]

>>> 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 <vidhi_goel=[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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
>> 
>> 
>