Re: [quicwg/base-drafts] Disagreement about CID Liveness (#1495)

Kazuho Oku <notifications@github.com> Fri, 29 June 2018 02:09 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 B8CEB130E4B for <quic-issues@ietfa.amsl.com>; Thu, 28 Jun 2018 19:09:27 -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 JISJ9GtEFf2X for <quic-issues@ietfa.amsl.com>; Thu, 28 Jun 2018 19:09:25 -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 C3AEF130E46 for <quic-issues@ietf.org>; Thu, 28 Jun 2018 19:09:25 -0700 (PDT)
Date: Thu, 28 Jun 2018 19:09:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1530238165; bh=0v4ipG/8PTucvWucNlJdA3LAv/V+ytPeb6F5bveSi3c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=jdFMB5duNtu37A3IpIx5L3o7OYl249ztwzjh1H8KRnpQ9kc3aSIwpxoFIFf8QAanx lWtwuVSdDwhj+fBCYv6y2N+8tjKdpEt3sPtTjfxrUii9th0iFWo1JI4feY3hyEuHtO OFrVUvhHmDgarDZgiZh9cC2wmdTs/rQtN3Sk1y/E=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abe1c4049df92684944b4a8475e876fcd13b6db8d492cf00000001174d56d492a169ce1412cb45@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1495/401226177@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1495@github.com>
References: <quicwg/base-drafts/issues/1495@github.com>
Subject: Re: [quicwg/base-drafts] Disagreement about CID Liveness (#1495)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b3594d4ef3b2_15fc3fce06a9ef84918db"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/fekd7wvih86UDsxEHdZ-g3Q6to4>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 29 Jun 2018 02:09:29 -0000

@MikeBishop 
> Possible solution: We might need to have the side forgetting CIDs explicitly inform the peer that it will no longer use or accept CIDs older than a certain cutoff. You have to remember old CIDs you've issued until this frame is acknowledged; upon receipt of this frame, you no longer consider the stateless reset tokens valid.

FWIW, an alternative approach will be to let each endpoint declare the maximum number of spare CIDs that the endpoint is going to keep.

An endpoint can request new connection IDs when the number of spares goes below the threshold that has been advertised by the peer, either by sending a `REQUEST_CONNECTION_ID` frame (which is proposed in #1496) or defining offering of CID as a reciprocal action (i.e. a client who wants more CID requests that by sending a new connection ID to the server; IIRC @martinthomson suggested that approach somewhere).

-- 
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/1495#issuecomment-401226177