IETF Logo Mail Archive

Re: [quicwg/base-drafts] Rejection of 0-RTT: start over? (#761)

MikkelFJ <notifications@github.com> Wed, 20 September 2017 06:25 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8141132F2C for <quic-issues@ietfa.amsl.com>; Tue, 19 Sep 2017 23:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.8
X-Spam-Level:
X-Spam-Status: No, score=-9.8 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_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 G22WwXXCqwQD for <quic-issues@ietfa.amsl.com>; Tue, 19 Sep 2017 23:25:58 -0700 (PDT)
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3213C1326ED for <quic-issues@ietf.org>; Tue, 19 Sep 2017 23:25:58 -0700 (PDT)
Date: Tue, 19 Sep 2017 23:25:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1505888757; bh=4bwD+Ftm4dccJLVaY49fNonrGsZv0kv7JVlXdRm6X+M=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=I9RI3mly3376pOYWQXCC0x7yiN4PvfirQ2UzPtz82sHB7p4VEwZQTQv4YLMaT3SLf iEQ19Y2Wtg88g/PFwZrrwRqZIAD0HBqeB9mxFL4bIYfUOIU4zUlwRHSlVA/cyFlujo UbTzLTpdBb7bCZX/MLIfWT7ee1Pcan1jyHn/eXpM=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abe18b6cea4f6a7d70706045422755b19c2b49807e92cf0000000115d9cbf592a169ce0f39dd03@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/761/330757047@github.com>
In-Reply-To: <quicwg/base-drafts/issues/761@github.com>
References: <quicwg/base-drafts/issues/761@github.com>
Subject: Re: [quicwg/base-drafts] Rejection of 0-RTT: start over? (#761)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59c209f55dc94_6ea13f9b1847ef80654e2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/PuAtCE-o-0hNL62-QpLKKGPdRXY>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Sep 2017 06:26:00 -0000

At least 2. would seem wrong because arbitrarily closing a stream at transport layer breaks application context.

1. Seems fair, but it complicates application development. Why should developers really care.
3. Might cause unexpected delays, and application might prefer connecting elsewhere.

The API could have an open flag indicating whether they want an error on 0-RTT, or treat the failed connect as a packet loss.

Thus, both 1. and 3. makes sense and might be selectable by application choise. In QUIC terms this means the transport should either fail connection with a specific error on 0-RTT or alternatively silently use 1-RTT via packet loss without disrupting the application depending on the users API configuration.

A 4th option could be to start over but having the API think it is the same connection. This is not a good idea because the API might have data buffers linked to the connection and moving those associations to a new connection might be complicated. Suddenly API connection and transport connection becomes different things.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/761#issuecomment-330757047

v2.31.3 | Report a Bug | By Email | System Status