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 70FFA132448 for ; Mon, 14 Aug 2017 15:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.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_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Xf2FxlYzRbJt for ; Mon, 14 Aug 2017 15:47:50 -0700 (PDT) Received: from o4.sgmail.github.com (o4.sgmail.github.com [192.254.112.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E618513244D for ; Mon, 14 Aug 2017 15:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=l0yqhE73ihFjR46kqVuyu+OXXMQ=; b=VcvmIN2p3xsQNi5m d6Ffefku45Q11wlCZD3tweHW4FK8cWXABsCsgnlC22qg8dd5/IWTiC+KivCHrAZg rTVgW7UViBmySRcCa6V+p5mckCUpA5lTzb1JfSeIBiLkocfIFQUzNTqnEM0HVSte u0nx8bgreKso/ef1kB/claEbmJ4= Received: by filter0847p1mdw1.sendgrid.net with SMTP id filter0847p1mdw1-1349-59922893-80 2017-08-14 22:47:47.941648334 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id rQ3BM6fIR0OOXkm0l3Pq0A for ; Mon, 14 Aug 2017 22:47:47.806 +0000 (UTC) Date: Mon, 14 Aug 2017 22:47:48 +0000 (UTC) From: janaiyengar Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Refactor the section on connection termination (#721) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59922893a5f5a_17d43faa6728fc34769e6"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: janaiyengar X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2/dxQq7NTrO8iz9Ge1e3tyREphU/qMat9pYD u5NaQUGILIvQxZWY1JX8QW0GlShWdxoyffeUF9CW8M5B8+7YB0/llBgoEwZQVcfwNbKt/iJGot7ITb nQqPdvjP7wz6QE1BQcz3DvFiVh84wVaVDiskW8CCt+rII50ZCTrJot2y0Zk8mHepzK3tXCOPFiv1qu 4= Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 14 Aug 2017 22:47:52 -0000 ----==_mimepart_59922893a5f5a_17d43faa6728fc34769e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit janaiyengar commented on this pull request. Thanks, Martin. A few comments, inline. > -received before sending a response. After this time, implementations -SHOULD respond to unexpected packets with a Public Reset packet. - - -## Stateless Reset {#stateless-reset} +of four ways: negotiated shutdown, idle timeout, immediate close, and a +connection reset. + + +### Negotiated Shutdown + +An application protocol might arrange to abandon a connection after negotiating +a graceful shutdown. The application protocol exchanges whatever messages that +are needed to cause both endpoints to agree to close the connection, after which +the connection is closed. A negotiated shutdown might not result in exchanging +messages that are visible to the transport. I don't understand what QUIC mechanism this is discussing -- specifically, why is this a QUIC connection termination mechanism? It seems to suggest that the app can use its own signaling to determine when to shutdown, but what QUIC mechanism is used for shutdown? > +the connection is closed. A negotiated shutdown might not result in exchanging +messages that are visible to the transport. + + +### Idle Timeout + +A connection that remains idle for longer than the idle timeout (see +{{transport-parameter-definitions}} becomes closed. Either peer removes +connection state if they have neither sent nor received a packet for this time. + +The time at which an idle timeout takes effect won't be perfectly synchronized +on peers. Endpoints might allow for the possibility that the remote side might +attempt to send packets before the timeout. In this case, an endpoint might +choose to retain enough information to generate a CONNECTION_CLOSE. Endpoints +MAY instead rely on sending Public Reset in response to packets that arrive +after an idle timeout. I don't think this advice is correct or adequate -- the time can be synchronized reasonably well. I would leave this subsection as is, if it needs to change in the future anyways. > +an endpoint maintains in this case, they MAY send the exact same +CONNECTION_CLOSE packet. + +Note: + +: This intentionally contradicts other advice in this document that recommends + the creation of new packet numbers for every packet. Sending new packet + numbers is primarily of advantage to loss recovery and congestion control, + which are not expected to be relevant for a closed connection. Retransmitting + the final packet requires less state at the server. + +Implementations SHOULD limit the number of CONNECTION_CLOSE messages they +generate. For instance, an implementation could exponentially increase the +number of packets that it receives before sending the packet containing +CONNECTION_CLOSE. Once enough time has passed to allow a peer to receive the +CONNECTION_CLOSE, an endpoint SHOULD discard per-connection state and MAY The current text says idle_timeout period of time, since that's the amount of time after which we expect the peer to drop state anyways. Is there a reason to change that? SImilarly, the current text recommends throttling responses, which is really important. I would argue for retaining that. -- 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/pull/721#pullrequestreview-56223350 ----==_mimepart_59922893a5f5a_17d43faa6728fc34769e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@janaiyengar commented on this pull request.

Thanks, Martin. A few comments, inline.

In draft-ietf-quic-transport.md:

> -received before sending a response.  After this time, implementations
-SHOULD respond to unexpected packets with a Public Reset packet.
-
-
-## Stateless Reset {#stateless-reset}
+of four ways: negotiated shutdown, idle timeout, immediate close, and a
+connection reset.
+
+
+### Negotiated Shutdown
+
+An application protocol might arrange to abandon a connection after negotiating
+a graceful shutdown.  The application protocol exchanges whatever messages that
+are needed to cause both endpoints to agree to close the connection, after which
+the connection is closed.  A negotiated shutdown might not result in exchanging
+messages that are visible to the transport.

I don't understand what QUIC mechanism this is discussing -- specifically, why is this a QUIC connection termination mechanism? It seems to suggest that the app can use its own signaling to determine when to shutdown, but what QUIC mechanism is used for shutdown?

In draft-ietf-quic-transport.md:

> +the connection is closed.  A negotiated shutdown might not result in exchanging
+messages that are visible to the transport.
+
+
+### Idle Timeout
+
+A connection that remains idle for longer than the idle timeout (see
+{{transport-parameter-definitions}} becomes closed.  Either peer removes
+connection state if they have neither sent nor received a packet for this time.
+
+The time at which an idle timeout takes effect won't be perfectly synchronized
+on peers.  Endpoints might allow for the possibility that the remote side might
+attempt to send packets before the timeout.  In this case, an endpoint might
+choose to retain enough information to generate a CONNECTION_CLOSE.  Endpoints
+MAY instead rely on sending Public Reset in response to packets that arrive
+after an idle timeout.

I don't think this advice is correct or adequate -- the time can be synchronized reasonably well. I would leave this subsection as is, if it needs to change in the future anyways.

In draft-ietf-quic-transport.md:

> +an endpoint maintains in this case, they MAY send the exact same
+CONNECTION_CLOSE packet.
+
+Note:
+
+: This intentionally contradicts other advice in this document that recommends
+  the creation of new packet numbers for every packet.  Sending new packet
+  numbers is primarily of advantage to loss recovery and congestion control,
+  which are not expected to be relevant for a closed connection.  Retransmitting
+  the final packet requires less state at the server.
+
+Implementations SHOULD limit the number of CONNECTION_CLOSE messages they
+generate.  For instance, an implementation could exponentially increase the
+number of packets that it receives before sending the packet containing
+CONNECTION_CLOSE.  Once enough time has passed to allow a peer to receive the
+CONNECTION_CLOSE, an endpoint SHOULD discard per-connection state and MAY

The current text says idle_timeout period of time, since that's the amount of time after which we expect the peer to drop state anyways. Is there a reason to change that?

SImilarly, the current text recommends throttling responses, which is really important. I would argue for retaining that.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59922893a5f5a_17d43faa6728fc34769e6--