Re: Hole in loss recovery algorithm?

Martin Duke <martin.h.duke@gmail.com> Thu, 30 April 2020 01:22 UTC

Return-Path: <martin.h.duke@gmail.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 3D4433A0C42 for <quic@ietfa.amsl.com>; Wed, 29 Apr 2020 18:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 E5k080wb9mAm for <quic@ietfa.amsl.com>; Wed, 29 Apr 2020 18:22:31 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 EC4803A0C41 for <quic@ietf.org>; Wed, 29 Apr 2020 18:22:30 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id f3so4432925ioj.1 for <quic@ietf.org>; Wed, 29 Apr 2020 18:22:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mXNJFqc2IfnFA1TMKnMUCbL1kMOGghNZ/XBXcNMVwA0=; b=WFXNcmjPtPsdNnT8dReqkw4HmELBeMtAMHUBqY/h8XTgLeGyAMEbWsoivHIts6/Vyc L2HcA419Q3N51xZ/OGr9j8hZDw1mZUEaIjdr15o5ppvLVY45rK7BDGqlLXm4CTHdaWgG aR7mV8pdUTkdA3h+4tGtI2OZpp/yN0Ifjk2evz8HjNKEkIR6dXwUdQfJMz7lHhw7FhwF DwSg95mxuncu7vltyVqURBchxlYzDB1UEYEc4E6HOFdA3NxjDYHIRmykKS2Jn/QU27Uw hnR3LSk/BW7MAen2H9ZiJpIWGKoIC+mAmOGDG0yVHSiO6cwOpZ7KYFtGbVA5nX6J9PS1 g0/g==
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=mXNJFqc2IfnFA1TMKnMUCbL1kMOGghNZ/XBXcNMVwA0=; b=XArgpPxSkPl7On0TOvPiukMwJEuV1ezPzfMW4lnNx1f1pp7LUK7ftstrm48BpLmuzZ STqvX2rVxJuKIvkwFOv5fkA5FckQnbm6NDBVq3ZUOX+UWZvBWosgpxnRwcob1hITbRaT TW9tRsVSWJ9TZfWVepMgebOYP11S+WcvQq+X8q6XOxqGwpMZwO7+kNI7QMue8DpHuBSx h31LeF3LpGNZWRnBJU0SEzj9t+c3qQCdf/4IqXtovsCkh84rw2+MFI8MDECGhpzQ43Q5 lLVTXI5Uu6qBp5E4JBYc+htdZEG2G5e+A34Nj7XYeEwGab6SQWs6tW9M6S23COYhX7+7 0pIQ==
X-Gm-Message-State: AGi0PuaeIL5bFNtaNYQBICP8LwZSNAUudXoFFC95S7/ejMlGXXzp2dIR 9GWDvqfQy8fwcRK+eB1yvy5imfNwmCa7E8vOZqY=
X-Google-Smtp-Source: APiQypJIPQbS9ZWqy6Kx+l6Mz6RsS3ODi1Cx8yii9a8pFidoAYSovzOL2TCK5Ni8DvxHCWwqkVBQ+dp+uRz7SQozprw=
X-Received: by 2002:a05:6602:15ca:: with SMTP id f10mr933240iow.51.1588209750340; Wed, 29 Apr 2020 18:22:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxQYh3W2GW-kxsBDw_Z8YLB3+-CSyLZsFQXp+LTxk92yNw@mail.gmail.com> <CAKcm_gNxoBYxiS4WxtjDs+mWdrBQMdxNkpbp+NfTjSH5XsT=8g@mail.gmail.com> <CAM4esxQAgqh4JmqSW+jULHxMUmNsdkgzyjz-oFvHjJozV+YS5w@mail.gmail.com>
In-Reply-To: <CAM4esxQAgqh4JmqSW+jULHxMUmNsdkgzyjz-oFvHjJozV+YS5w@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 29 Apr 2020 18:22:19 -0700
Message-ID: <CAM4esxS9-EMDnmhubsNi4aLG7aJFG-+fZy2g_R80Ub12CWLgTA@mail.gmail.com>
Subject: Re: Hole in loss recovery algorithm?
To: Ian Swett <ianswett@google.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ff79f105a477e50d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/dDeHkDXDXfD6qRQcDhHZAIHa_Ss>
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: Thu, 30 Apr 2020 01:22:36 -0000

Filed #3613 <https://github.com/quicwg/base-drafts/issues/3613>. A couple
of more notes:

- HANDSHAKE_DONE doesn't cover the client case where all 0RTT is lost and
the client doesn't have any more data to send. It may never send a 1RTT
ack-eliciting packet.
- Doing it when discarding the keys works, but it would be better to do it
when the handshake completes, not confirms. That's when the 1RTT PTO
prohibition lifts.

On Wed, Apr 29, 2020 at 5:59 PM Martin Duke <martin.h.duke@gmail.com> wrote:

> I would personally put it both there and in 5.2.1.
>
> On Wed, Apr 29, 2020 at 3:03 PM Ian Swett <ianswett@google.com> wrote:
>
>> When the Client Finished arrives, the server is handshake complete, so it
>> should arm PTO for the 1RTT data, though I don't see text making that
>> explicit.  Should it be added here
>> <https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-recovery.md#discarding-keys-and-packet-state-discarding-packets>
>> ?
>>
>> In the psuedocode, the PTO timer is reset when a PN space(the server's
>> Handshake in this case) is dropped.
>>
>> Also, after the Client Finished arrives, the server sends HANDSHAKE_DONE,
>> which would also re-arm the timer and fix the issue, but I'd rather not
>> rely on HANDSHAKE_DONE to solve all the problems.
>>
>> On Wed, Apr 29, 2020 at 5:23 PM Martin Duke <martin.h.duke@gmail.com>
>> wrote:
>>
>>> I'm probably missing something silly, but I'll file an issue if there is
>>> in fact a problem here:
>>>
>>> - Server sends its handshake flight and some 1RTT data.
>>> - The PTO is timer is set for the handshake data only per 5.2.1 of
>>> quic-recovery.
>>> - HS ACKs arrive, but the 1RTT is lost.
>>> - Client Finished arrives.
>>>
>>> If this order of operations occurs, and there is no further 1RTT
>>> communication, is the 1RTT ever going to recover? A literal reading of the
>>> spec, if IIUC, is that when the HS acks arrive we're going to cancel the
>>> PTO timer and, as the handshake is not yet complete, we will not restart it
>>> for the outstanding 1RTT.
>>>
>>> A sentence saying you have to start it when completing the handshake, if
>>> 1RTT data is outstanding, would solve the problem. Perhaps I'm missing
>>> something more obvious?
>>>
>>