Re: [quicwg/base-drafts] Specify whether 0-RTT MAY use the same CID as Initial packets (#1721)

Martin Thomson <notifications@github.com> Wed, 05 September 2018 06:47 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 23F94130DF2 for <quic-issues@ietfa.amsl.com>; Tue, 4 Sep 2018 23:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 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, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 nL-PBSlyc5ew for <quic-issues@ietfa.amsl.com>; Tue, 4 Sep 2018 23:47:28 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066DF126CB6 for <quic-issues@ietf.org>; Tue, 4 Sep 2018 23:47:27 -0700 (PDT)
Date: Tue, 04 Sep 2018 23:47:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1536130047; bh=Gxbe6iQWc6dPNIg+eXcmAClDLf7m+AbFPbZ4XNenJDk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=HrFOnl5nNnQKtrtihrxsYk08K4UsAEuZIivXtQV3khTiBiLP0bU26+hHgYFaFS923 H//wDj8KmjzvP1qU4pEY4vDThCzD8JndQEcqOLi2fuiQqhlIa5QPwXyNoeTVo3XvYd QsO/qHCnO3jbHFc4+RpJHNEYwzDnGI+pSaBOLw0A=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab08be5a5f926d0e0a764457ae5f50d2ec215cafe192cf0000000117a73dff92a169ce1547f95a@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1721/418618068@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1721@github.com>
References: <quicwg/base-drafts/issues/1721@github.com>
Subject: Re: [quicwg/base-drafts] Specify whether 0-RTT MAY use the same CID as Initial packets (#1721)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b8f7bff43c4_30a93f9dd70d45bc75126f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/x9rAYFK756B-IJwMCmepWGwPnB4>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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, 05 Sep 2018 06:47:30 -0000

I think that this is the only sensible outcome based on the description we have of the problem.

We should check that this is going to work though.  The current design intentionally has all 0-RTT with the same connection ID so that we could guarantee (ish) that it was consistently routed.  But that was based on the understanding that most 0-RTT in most cases would be sent prior to getting the server's first handshake flight.  Having the switch in connection ID happen, but be relatively rare (you would need partial loss of the server flight).  The assessment was that it would only cause problems.

With Stream 0, we have EndOfEarlyData, so a change in connection ID based on these rules would always happen, and so we'd expect to not see any odd bugs.  Unless I hear screams, I will make a PR following Christian's suggestion (though, note to self: we probably just want to remove the special handling text rather than add more of it, this might be a change that involves deleting text more than adding it).

-- 
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/1721#issuecomment-418618068