Return-Path: 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 59B5612087E for ; Wed, 6 Nov 2019 05:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 qL44j6i2g27o for ; Wed, 6 Nov 2019 05:13:03 -0800 (PST) Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD624120835 for ; Wed, 6 Nov 2019 05:13:03 -0800 (PST) Received: from github-lowworker-25680bd.va3-iad.github.net (github-lowworker-25680bd.va3-iad.github.net [10.48.17.61]) by smtp.github.com (Postfix) with ESMTP id E88448C0C31 for ; Wed, 6 Nov 2019 05:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573045982; bh=4Xk1Zydp70EByfSluaROO5Z+rE07a2F9WpUh+IdPlEM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=2RLQVR4DjgwNK+AYzr3EZpHZAw+/niqBhdgsVWjIVytSYZbOVNdI71C55runyJu1s M88Aw44WX1nRIGStn0JlMHnOW+rOYyQXoHp0WpY1uqkHEdfN8qUm4mC7ZTaVef6ayQ uLyvXCBi6237yAfY4iNoV00haFPk7kxAJGvq1SeY= Date: Wed, 06 Nov 2019 05:13:02 -0800 From: Kazuho Oku Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] active_connection_id_limit interacts poorly with Retire Prior To (#3193) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5dc2c6ded6422_378e3fd4beecd95c212969"; 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: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 13:13:05 -0000 ----==_mimepart_5dc2c6ded6422_378e3fd4beecd95c212969 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the model that @erickinnear's has described is accurate.=0D =0D At the same time, it seems alarming to me that we have failed to incorpo= rate that model into the text.=0D =0D Specifically, as @marten-seemann points out, we have the following text:=0D= > Upon receipt, the peer MUST retire the corresponding connection IDs and= send corresponding RETIRE_CONNECTION_ID frames.=0D =0D and FWIW also:=0D > Connection IDs that are issued and not retired are considered active; a= ny active connection ID can be used.=0D =0D that both assume that all connections IDs are expected to be retired. But= as @erickinnear points out, when the issuer provides more than what `act= ive_connection_id_limit` recommends, those connection IDs are not expecte= d to be retired.=0D =0D I'd like to point out that the way we control the active CIDs sticks out = from other "crediting schemes". For all other crediting schemes (i.e. MAX= _DATA, MAX_STREAMS, MAX_STREAM_DATA), there is a hard limit. It is a prot= ocol violation when the sender exceeds the allowed maximum. It is only fo= r this active_connection_id_limit - RETIRE_CONNECTION_ID pair that we do = not enforce the sender adhering the limit.=0D =0D Considering these aspects, and the fact that implementors are complaining= about the complexity caused by "SHOULD NOT," I think it's worth consider= ing changing the "SHOULD NOT" of "an endpoint SHOULD NOT provide more con= nection IDs than the peer=E2=80=99s limit" to "MUST NOT."=0D =0D The counterargument might be that it's an additional complexity; but I do= ubt if it's that important, compared to the importance of resolving the c= onfusion that we have now.=0D =0D As @erickinnear have stated, the issuer is excepted to stick to providing= *N* active CIDs, where N is a constant throughout the lifetime of a conn= ection. No other approach works. So the *complexity* that is to be added = by changing the "SHOULD NOT" to "MUST NOT" is that the issuer would be re= quired to set N to no greater than the value of "active_connection_id_lim= it" provided by the peer.=0D =0D I think we can pay that cost for buying a consistent design (that avoids = the confusion).=0D =0D -- =0D You are receiving this because you are subscribed to this thread.=0D Reply to this email directly or view it on GitHub:=0D https://github.com/quicwg/base-drafts/issues/3193#issuecomment-550302894= ----==_mimepart_5dc2c6ded6422_378e3fd4beecd95c212969 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think the model that @erickinnear's has described is a= ccurate.

=0D

At the same time, it seems alarming to me that we have failed to inco= rporate that model into the text.

=0D

Specifically, as @marten-seemann points out, we have = the following text:

=0D
=0D

Upon receipt, the peer MUST retire the corresponding connection IDs an= d send corresponding RETIRE_CONNECTION_ID frames.

=0D
=0D

and FWIW also:

=0D
=0D

Connection IDs that are issued and not retired are considered active; = any active connection ID can be used.

=0D
=0D

that both assume that all connections IDs are expected to be retired. = But as @erickinnear points out, when the issuer provides m= ore than what active_connection_id_limit recommends, those c= onnection IDs are not expected to be retired.

=0D

I'd like to point out that the way we control the active CIDs sticks o= ut from other "crediting schemes". For all other crediting schemes (i.e. = MAX_DATA, MAX_STREAMS, MAX_STREAM_DATA), there is a hard limit. It is a p= rotocol violation when the sender exceeds the allowed maximum. It is only= for this active_connection_id_limit - RETIRE_CONNECTION_ID pair that we = do not enforce the sender adhering the limit.

=0D

Considering these aspects, and the fact that implementors are complain= ing about the complexity caused by "SHOULD NOT," I think it's worth consi= dering changing the "SHOULD NOT" of "an endpoint SHOULD NOT provide more = connection IDs than the peer=E2=80=99s limit" to "MUST NOT."

=0D

The counterargument might be that it's an additional complexity; but I= doubt if it's that important, compared to the importance of resolving th= e confusion that we have now.

=0D

As @erickinnear have stated, the issuer is excepted to = stick to providing N active CIDs, where N is a constant througho= ut the lifetime of a connection. No other approach works. So the comp= lexity that is to be added by changing the "SHOULD NOT" to "MUST NOT= " is that the issuer would be required to set N to no greater than the va= lue of "active_connection_id_limit" provided by the peer.

=0D

I think we can pay that cost for buying a consistent design (that avoi= ds the confusion).

=0D =0D

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on= GitHub, or unsubscribe.3D""

=0D = ----==_mimepart_5dc2c6ded6422_378e3fd4beecd95c212969--