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

[Vidhi Goel <[e-mail]>]

>>>> 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.

Ah, ok. Thats what I did :-)
If we don’t include TIMESTAMP in bytes_in_flight, I worry if increasing on-wire bytes in flight without reflecting at the host could cause the host to cause congestion inadvertently and not react to it if it is only sending ACKs + TIMESTAMPs.

OTOH, if it was like PADDING, it would help to avoid congestion and we wouldn’t send TIMESTAMP when out of CC limit. In that case, we would send only pure ACKs (without TS frame)

What do you think?

Thanks,
Vidhi
> On Mar 17, 2021, at 11:57 PM, Christian Huitema <[e-mail]> wrote:
> 
> 
> 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 <[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>] 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