IETF Logo Mail Archive

Re: [quicwg/base-drafts] Retire My Own CID (#2645)

Nick Banks <notifications@github.com> Thu, 06 June 2019 13:22 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 61AA81200F9 for <quic-issues@ietfa.amsl.com>; Thu, 6 Jun 2019 06:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.02
X-Spam-Level:
X-Spam-Status: No, score=-7.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, 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 46enz_W6a9zn for <quic-issues@ietfa.amsl.com>; Thu, 6 Jun 2019 06:22:51 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882D912007C for <quic-issues@ietf.org>; Thu, 6 Jun 2019 06:22:51 -0700 (PDT)
Date: Thu, 06 Jun 2019 06:22:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1559827370; bh=7pXq4PMh9q/cs5rvZHqJkdOWnt4bWBthiiCnKIEjyW8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=C8S3KbjWH0u1rG9SZK89z06s/vUAgU43Vt2uaom+PUVEBboW1cCRbyUYWk/Kgtxio HevLJnE6e1hK7GS6DTbQbpQcnsjs/Yri6IQtgVDopDbGOOLHO7+aGrkgbLcvuIGrZa wUcIKSByYq3gStA6oVqb/p8scRfvm7r4r+ObVIcg=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYFAXBOO6PY7UT6U7N3AZDCVEVBNHHBUAUCHA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2645/499491414@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2645@github.com>
References: <quicwg/base-drafts/issues/2645@github.com>
Subject: Re: [quicwg/base-drafts] Retire My Own CID (#2645)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cf913aa588e3_27ea3f998bacd960208918"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/UdDS_-x28LOSnLRfAqbFJvo8ouM>
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: Thu, 06 Jun 2019 13:22:54 -0000

I'm going to try to answer all the comments/questions from both the Issue and the PR here, so as to not clutter up the PR.

It now seems that most people actually prefer the immediate switch of the CIDs instead of allowing for delay. I agree key update is a good example / pattern to follow here. You get a packet with the NEW_CONNECTION_ID frame to replace existing CIDs, you locally update all CIDs and then you mark the packet for ACK. 

@DavidSchinazi I understand that some implementations might have extra difficulties, but I'm not sure why it would be that much different from key update. Additionally, you only ACK a packet after it has been fully processed, so if you process the NEW_CONNECTION_ID frame before the "packet fully processed state" and update CIDs there, then there shouldn't be an order of operations problem.

-- 
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/2645#issuecomment-499491414

v2.23.0 | Report a Bug | By Email