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

[Lucas Pardue <[e-mail]>]

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, <[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
>
>
>