Re: [quicwg/base-drafts] Why are we bothering to number CIDs? (#2159)

Mike Bishop <notifications@github.com> Thu, 13 December 2018 22:33 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 8BCBA130EB1 for <quic-issues@ietfa.amsl.com>; Thu, 13 Dec 2018 14:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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] 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 Z7M0SCwcHz30 for <quic-issues@ietfa.amsl.com>; Thu, 13 Dec 2018 14:33:51 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538F2130EA2 for <quic-issues@ietf.org>; Thu, 13 Dec 2018 14:33:51 -0800 (PST)
Date: Thu, 13 Dec 2018 14:33:49 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544740429; bh=rK8Y+VwqxSlhf9HmyNpLmI5H9p1GV2wXJZZkP37SP/4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=mmp6G+fpqO6b+LM0YGISyyRkT12JV4bAvM2wNtDeEYsWpyabPWg28MLJKH56Z1BQK aBfBUTDfTvN1NBlIcUyA1SBGa+Iq99vPFWtHG3ukntCpyRrE9TMr/pnJsDaP8X/Myv OfRslZ9l1+S4iSKoHWBqkZ7dCr39kuUlRlkF1ZXE=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba820dad3632e24fb0daba16925c32a8c6e2322bc92cf00000001182aa04d92a169ce174c07b8@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2159/447145188@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2159@github.com>
References: <quicwg/base-drafts/issues/2159@github.com>
Subject: Re: [quicwg/base-drafts] Why are we bothering to number CIDs? (#2159)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c12de4deeffc_4aa3f988d2d45b43657a7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/rbxokApb_YwXME3kaMWpzeOcwsg>
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, 13 Dec 2018 22:33:54 -0000

Because you're not realistically going to retain a total history of all CIDs you've ever seen.  You MAY treat it as an error if you notice that one recurs, so that servers are disincented from doing so, but you're not obliged to check that over the whole connection lifetime.  However, without maintaining that history for a sufficiently long time, you then can't differentiate for certain between a retransmission of an old NCID frame and a new issuance of the same CID (an error, but one you might miss).  Therefore, you could wind up in a state where the peers disagree about whether a CID is still live.

The options were a requirement to keep history for a certain length of time (and hope that packets don't get delayed longer than whatever arbitrary timeout we pick) or using sequence numbers and allowing tracking with a similar data structure as that which tracks whether Stream IDs are not-yet-open, open, or closed.

-- 
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/2159#issuecomment-447145188