Re: Questions about recovery draft 29

[Jana Iyengar <[e-mail]>]

Spencer,

It's a good idea, but I think it's a bit early to think of a roadmap. The
core protocol components necessary for QUIC are exactly the three documents
we have right now, nothing more. Once we have more extensions, other
changes in more drafts, it might make sense to think of a roadmap.

- jana

On Mon, Jul 13, 2020 at 7:40 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

> Just to chime in here, so top-posting.
>
> Matt is correct (that specifications != implementations), but I note that
> the transport area has produced, and revised,
> https://datatracker.ietf.org/doc/rfc7414/ (A Roadmap for Transmission
> Control Protocol (TCP) Specification Documents", that go through what Matt
> characterized as the 'myriad RFCs that loosely define "IETF TCP"'
>
> The TCP community used Informational RFCs to document what's a good idea
> and what's a bad idea at the per-specification level ("really important to
> implement this, that is a really bad idea so don't implement it", because
> RFCs were the tools we have.
>
> It might be worth thinking about the form a "QUIC Roadmap" might take,
> given that we now have wikis, gitbub, and other tools that could allow the
> QUIC roadmap and implementations to be more aware of each other, especially
> if this was more granular than "this document".
>
> We talked about this briefly at IETF 106 in TSVAREA. From the minutes at
> https://datatracker.ietf.org/meeting/106/materials/minutes-106-tsvarea-02
>  ...
>
>    - Ted: Lots of creativity right now. people need to understand what
>    they are doing *to* the protocol, not just *with* it. We should write "the
>    hitchhiker's guide to QUIC". Intended for all audiences.
>    - Mirja: That's what applicability and mgmt docs are for.
>    - Ted: That's not what I'm looking for.
>    - Spencer: Imagine if TCP roadmap had started before there were 150
>    RFCs!
>
> Did people have thoughts about that?
>
> Best,
>
> Spencer
>
>
> On Thu, Jul 9, 2020 at 2:10 PM Matt Joras <[e-mail]> wrote:
>
>> I won't offer specific answers to all your questions as Ian or Jana
>> likely have better ones, however I'd like to make a general point
>> about this line of questioning: Linux TCP != IETF TCP, or, said
>> another way, Implementations and Specifications are not the same
>> thing. Recall that QUIC is a series of specifications being developed
>> by the IETF, similar to the myriad RFCs that loosely define "IETF
>> TCP". Linux's TCP stack is one such interpretation/implementation of
>> TCP, and while it can inform the decisions of IETF workings, it should
>> not be an undue determiner of the development of said specifications.
>> Similarly we have an even wider and more diverse collection of QUIC
>> interpretations/implementations in various states of maturity and
>> deployment. Many diverge, sometimes heavily, from the specifications
>> especially insofar as recovery is concerned. Chrome and us (mvfst) use
>> BBR as the default congestion controller, others use Cubic or HSTCP or
>> who knows what else. Chrome, AFAIK has a notion of adaptive reordering
>> similar to Linux TCP and modifications to the draft-suggested time
>> thresholds and PTO strategy.
>>
>> Whether some of these changes should be codified in the QUIC
>> specifications is a good question. My hope is that these best
>> practices will gain deployment experience and drive consensus at the
>> IETF in future iterations of QUIC recovery and encounter fewer
>> roadblocks than innovations based on TCP have historically
>> experienced. As it is now though, QUIC's charter, by design, largely
>> limits us to the adaptation of recovery and congestion control work
>> that has already gained consensus via other IETF RFCs. That being
>> said, what we have in the recovery specs may not be the "state of the
>> art" exactly, but it is still quite good and I would argue has other
>> significant advantages over what is commonly deployed in TCP, even
>> Linux TCP.
>>
>> Matt Joras
>>
>> On Thu, Jul 9, 2020 at 9:22 AM Jonas Reynders
>> <[e-mail]> wrote:
>> >
>> > I have been looking at the recovery draft 29 of QUIC and comparing it
>> to TCP, specifically the linux implementation in kernel v5.4. I have a
>> couple of questions about the design choices that differ from TCP in linux.
>> >
>> > The first question is in regards to ack-based loss detection where QUIC
>> uses both a packet-threshold and time-threshold method. Looking at the
>> linux implementation (kernel v5.4), TCP uses only a time-threshold method
>> (RACK) as default. From my understanding both methods were used in linux
>> some time ago, around the time it was clarified to use both methods for
>> QUIC as well. However since then TCP changed to RACK only as the default,
>> from what I found out it was due to tests at google detecting a 10%
>> reduction in recovery latency (reference:
>> https://patchwork.ozlabs.org/project/netdev/cover/[e-mail]/).
>> My question is why QUIC still recommends using both methods as default? I
>> can understand that in a datacenter context, where RTT values are really
>> low, RACK can struggle due to timers not being fine grained.
>> >
>> > My second question is in regards to the time threshold
>> calculation(6.1..2 in recovery draft). QUIC uses a constant value (9/8) for
>> the time threshold, whilst in linux an adaptive threshold is used in the
>> form of a reordering window variable. In the recovery draft it is mentioned
>> that adaptive thresholds can be used, however it’s not mandatory. Is there
>> a reason why QUIC doesn’t use the linux method for an adaptive threshold?
>> The draft also mentions that reordering can be more common in QUIC and that
>> adaptive thresholds have the advantage of being more aggressive when there
>> is no reordering. The same question for the packet threshold, QUIC uses a
>> constant threshold of 3 packets whilst in linux there is an adaptive
>> threshold.
>> >
>> > My last question is that of merging the TLP and RTO into PTO. If I
>> understand correctly, this was possible due to probe packet being
>> ack-eliciting. And, that the time-threshold method would detect loss in a
>> similar manner to RTO, with the RTO also causing a congestion collapse if
>> no acks were received for consecutive RTOs. I assume that keeping RTO would
>> unnecessarily complicate things, is that correct?
>>
>>