Re: Questions about recovery draft 29

Ian Swett <ianswett@google.com> Mon, 20 July 2020 14:15 UTC

Return-Path: <ianswett@google.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F7B3A0AFD for <quic@ietfa.amsl.com>; Mon, 20 Jul 2020 07:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVOUog3YBr5N for <quic@ietfa.amsl.com>; Mon, 20 Jul 2020 07:15:13 -0700 (PDT)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B77D3A0AFB for <quic@ietf.org>; Mon, 20 Jul 2020 07:15:13 -0700 (PDT)
Received: by mail-yb1-xb36.google.com with SMTP id 134so8352692ybd.6 for <quic@ietf.org>; Mon, 20 Jul 2020 07:15:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o5FeDvGtENL7BTmS9djfLrH+JfukYR2f8DnKE9loUws=; b=npQVczIcfJ+x9Z1PzPY9SGD8pbakXQR7BL9sc0jlapcNqA10/sTkjm24QhrxCkuCwp 2f7IfVCKqFkjjvfpfbicieLnB+dumt+ID5y7gw9mjrld1CdiWBiuVDT4DYHGHwAsk0hu BtnNCRd0EVhVmiNkmjiKDIQglSgxuEKgCdLL2ULQqtRdf571XLCiF6Yf+xVlXo5OxDnG aZIkdffeIsQLwJ6ULNCij6rKysy/3qlBxlK/RVBTj5/bdleWyILl5UCat9nN1mVV7q16 7scKVjAm7uo2UDDiHUDtnoWvde/Tdg4OVYyFLso8du1a1d/1F5AzBPbFGGWHuKd+yS/l ylCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o5FeDvGtENL7BTmS9djfLrH+JfukYR2f8DnKE9loUws=; b=lsa4CsoKmFYJWbYvytM5VwZvCnvHCGPlbEWME7FhNHEC+5pThmFcY6YeJGToNMHtRr vAM7JY0W1ofaKU/NIHQkU7fNYw6PQW/Jq7FeuSquhS1HYjycdBIKaLPsK5mzSFFFmx+h M6zziMEML55dv0X+G3D6s62Xp08e6c/U70acDNQ58nXnhy0BT4qvCU40vmcAJaZknPr3 XzFnwpxDWaI9K3GQ56DOnbbKO5bhtrZw1FPKTY/urq+M1/WGPgoA6TBGBVuZh5wcsuPJ hwYsmLGgFDtFfDKyEof1ahYd3bIbzpN5dH6p6PkigedcfZflPniZvCDcjMKFEP9fL8TZ jrOQ==
X-Gm-Message-State: AOAM530vtCiHToaNjvdCbvFmfZwe8gdOANzz+A+Vn8R/phrkDQlWeHeQ PdKj3MTx+nPdY+7sB905x1uLtr2sE/ys8hBIKoje8Q==
X-Google-Smtp-Source: ABdhPJykQ/crMq3hnVdGGTF/rtwiATXaT07qKFBxdmcltnPsgCA7YwmF7T/pTbiu85dXYBKtKos8byKSXymqcnJVTQI=
X-Received: by 2002:a25:b78a:: with SMTP id n10mr33393175ybh.494.1595254512039; Mon, 20 Jul 2020 07:15:12 -0700 (PDT)
MIME-Version: 1.0
References: <CABC-CqayJAeipEhsTf4h8rkUVQvYLd=1wF4UBMkaYSNMfvgnXw@mail.gmail.com> <CADdTf+jxKyPw_zfJ6FWCz230rXqg83d7rQJhKBteBvoLCut1RQ@mail.gmail.com> <CAKKJt-dgEmOtvXR8hVT9qf+YgSe3m9LMUuE6=csU28j+j1V_ZQ@mail.gmail.com> <CACpbDce=G=ou1F5dQx3r+TbzACrJRkQkKO7OviTHvd2QxFKTyg@mail.gmail.com>
In-Reply-To: <CACpbDce=G=ou1F5dQx3r+TbzACrJRkQkKO7OviTHvd2QxFKTyg@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Mon, 20 Jul 2020 10:14:59 -0400
Message-ID: <CAKcm_gMsW=AC6_HhzidXgk_qL9Y1K78F8exEytQFYdTNQaq4xg@mail.gmail.com>
Subject: Re: Questions about recovery draft 29
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, IETF QUIC WG <quic@ietf.org>, Jonas Reynders <jonas.reynders@student.uhasselt.be>, Matt Joras <matt.joras@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000084cfaf05aae0225e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/1-RUOlH7SKXoPFKmgwcy1TWt6lc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2020 14:15:16 -0000

+1 to Jana's point about QUIC not having a TCP-style sequence number, so
it's always time-based in some sense.

There was a recent discussion of whether adaptive thresholds should be
recommended(Issue #3571 <https://github.com/quicwg/base-drafts/issues/3571>)
which I opened after running experiments and enabling adaptive packet
thresholds by default in the Chromium implementation.  The current text
contains the consensus decision to highlight the value of adaptive
reordering, but not make any normative statements.

For TLP and PTO, QUIC recovery started with both, but it added excess
complexity without any recognizable value, so they were merged into PTO.
Even when both TLP and RTO existed in the recovery draft, they were subtly
different from TCP's, so a new mechanism with a new name made sense.

On Fri, Jul 17, 2020 at 11:15 PM Jana Iyengar <jri.ietf@gmail.com> wrote:

> 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 <
> spencerdawkins.ietf@gmail.com> 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/
>> <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 <matt.joras@gmail.com
>> <matt..joras@gmail.com>> 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
>>> <jonas.reynders@student.uhasselt.be> 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/20180516234017.172775-1-ycheng@google.com/).
>>> 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?
>>>
>>>