IETF Logo Mail Archive

Re: Rejecting 0-RTT (was Re: Split error codes in two)

Jana Iyengar <jri@google.com> Thu, 07 September 2017 22:51 UTC

Return-Path: <jri@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 06590132025 for <quic@ietfa.amsl.com>; Thu, 7 Sep 2017 15:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 FJlmEyIY7PoQ for <quic@ietfa.amsl.com>; Thu, 7 Sep 2017 15:51:23 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 C483112895E for <quic@ietf.org>; Thu, 7 Sep 2017 15:51:23 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id v72so954253ywa.3 for <quic@ietf.org>; Thu, 07 Sep 2017 15:51:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hD2afuqixAUKFIgNhLfmtBRMbBP5tKCIkUirpdb+Fxo=; b=C1qB1XLVqOYrBLDWcu6Uv87xtLZGwJtH1rxhi0De4a/KMPrPsMnAvuKWF/+YuSWF00 NULuZj16c78E6DXAfvlLaJmsy3RNQt4tCVdXSLX7P/qzvd9qpTyvMljDpHa1qHnn5Pj4 1n6EGYnDRAI+etPB1bOXm7Ye3Vb08/P2IoaOzZ9gn0QrzVXC5yQfwRgjwO6tPp9sK4pY 6wy3IAGTg/yb4Qa9kWZaYeQbVSA8jkQB9WJcugNvZXNploNHohSpdfgV339PJdThQ0AO OIdFF2FEooc6wqXK5Gpca7iSbU9Keo8Iz40on+3CtCIrlgc0RJNDh1Kx/lUOzEXyt0gD wtRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hD2afuqixAUKFIgNhLfmtBRMbBP5tKCIkUirpdb+Fxo=; b=juWIiOyx2Vkw4J1D7Y+5A99HB0o8cOQzqppFosUhh/ndebKZLAe8nQ3CGLpJPdV6zv ItqOkxOjC5jsBPZW5PyK+3YQ/MRP6PSDQMNAWSnWdl24wcd6pXgkDoWlCHaJ+3fhiBEP oX6XuITHU0wZI5e2PCjfku8IcmFwPotoWmMgKwZMy5VgKFKjZw2S+y74l2Q18x9aYVSy 53LhKXuY0Y/GXycgj9emnVLrHc67DPDK1iuutApMu0eZ5yobzyd9hI9QBQ7BbZV2hZ5H EOrzlGlXC6gYEWRa0Rr5CBUbVlsYNfsFsLHBr6kpygh678HXV8cQRu/6UZs8d628tuxL Wy+g==
X-Gm-Message-State: AHPjjUhB7gkeZpAmbnr7rVnZF/U6M9Y/aa7p5lsVWP1nXD1lPWrOKUH2 AdlomPG0eDInAE2SooyPSPXJQYGMhq/zKxQ=
X-Google-Smtp-Source: ADKCNb4ju9ftWaUkYjQecv1dX0vQB6QG07vT6RNl+1bSvDHZW6NGvqjmnpcG5NeTVpdqYsTCP39IXCfTUNFa9aIto0M=
X-Received: by 10.37.248.32 with SMTP id u32mr796518ybd.137.1504824682637; Thu, 07 Sep 2017 15:51:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.118.133 with HTTP; Thu, 7 Sep 2017 15:51:22 -0700 (PDT)
In-Reply-To: <9c61c238-2c83-b5a7-9739-4094ef36ac57@huitema.net>
References: <CABkgnnVJrh7p===3+qcWxvSU3DJFK06Tk4QEBXvcOV7cB55+JQ@mail.gmail.com> <e6243b56-a285-e121-1cea-9f215379ebe7@huitema.net> <CABkgnnXxCGVnY5qRuja1uEvQZpOooHDDJAKwuEQMMDYL3dBSuA@mail.gmail.com> <112340f5-57ce-b647-2be4-e21373039b63@akamai.com> <9c61c238-2c83-b5a7-9739-4094ef36ac57@huitema.net>
From: Jana Iyengar <jri@google.com>
Date: Thu, 07 Sep 2017 15:51:22 -0700
Message-ID: <CAGD1bZYF18M75sz6ZJ6HnaaMmNh3HyB3GyK1eONXbAPWyD5SgA@mail.gmail.com>
Subject: Re: Rejecting 0-RTT (was Re: Split error codes in two)
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="f403045da54ea8d7e80558a14cf5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/a-bQkqsOdO7DSs29yv8PZeBolOQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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, 07 Sep 2017 22:51:27 -0000

>
> If we assume that a clear text ACK cannot acknowledge encrypted packets,
> 0-RTT data packets cannot be acknowledged before the connection is
> established. The sender can thus send at most an initial window.
>
> From a congestion control point of view, how should "reset after 0-RTT
> reject" differ from starting a new connection?
>

I  wouldn't do anything different with the controller. The sender is not
going to receive acks for these packets, so it's best to do a clean slate
and start again with the initial window. The sender *could* do something
more complicated, like wait "a while" to let the network drain, but without
knowing what network bandwidth is,  the sender would still be in the dark
about how long to wait. Any wait time here will be wrong, just as wrong as
the initial window. So, I would reset the controller's state to initial
state.

v2.23.0 | Report a Bug | By Email