IETF Logo Mail Archive

Re: [quicwg/base-drafts] NEW_CONNECTION_ID text is too restrictive on receivers (#3534)

martinduke <notifications@github.com> Thu, 19 March 2020 23:13 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 C583D3A11E5 for <quic-issues@ietfa.amsl.com>; Thu, 19 Mar 2020 16:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, 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 mfUHkSzkzBME for <quic-issues@ietfa.amsl.com>; Thu, 19 Mar 2020 16:13:10 -0700 (PDT)
Received: from out-16.smtp.github.com (out-16.smtp.github.com [192.30.254.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509C33A11A9 for <quic-issues@ietf.org>; Thu, 19 Mar 2020 16:13:10 -0700 (PDT)
Received: from github-lowworker-2300405.va3-iad.github.net (github-lowworker-2300405.va3-iad.github.net [10.48.17.39]) by smtp.github.com (Postfix) with ESMTP id 7FF061204FF for <quic-issues@ietf.org>; Thu, 19 Mar 2020 16:13:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584659589; bh=zu8jTRon0Re7FPACtdZhQfgE+cEWN+ibR8v5HOPFioI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qJURRuxOazot9MgV5hacLz+kVwD08FMu/D+/jmziImfvecU4p18G/d1THGTiR89Bf DCSGGWjYW4YDrJw0H4J0o8OYcwoQG1eWwGAjVqld/sy6jlRWKJW0zAy5YTjuoFZiYK L94anx3HD5KbIGF1MAZ3bC2m3eK4R5ui5a7RzpCQ=
Date: Thu, 19 Mar 2020 16:13:09 -0700
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4ILNYPC4YABLEYNSV4P7OYLEVBNHHCFWJJQQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3534/601458378@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3534@github.com>
References: <quicwg/base-drafts/issues/3534@github.com>
Subject: Re: [quicwg/base-drafts] NEW_CONNECTION_ID text is too restrictive on receivers (#3534)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e73fc853aada_58493fd27f2cd96811903c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/_7GUs-uH0dyY2KwWfESZCInzQzk>
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, 19 Mar 2020 23:13:12 -0000

> I think we already prohibit such behavior through the use of active_connection_id_limit TP. 

I was probably unclear. For a while, our implementation was doing something dumb: each time it got a new CID, it started using it and retired all previous ones regardless of Retire Prior To. This created infinite loops where the client was trying to make sure that we always had two CIDs. We should probably warn against that.

Please see if the text in the PR is clear enough.

-- 
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/3534#issuecomment-601458378

v2.23.0 | Report a Bug | By Email