HTTP/QUIC GOAWAY when there is no client request?

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Mon, 05 March 2018 12:20 UTC

Return-Path: <Lucas.Pardue@bbc.co.uk>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504DC12D778 for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 04:20:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 k0W3mmDnTJxs for <quic@ietfa.amsl.com>; Mon, 5 Mar 2018 04:20:21 -0800 (PST)
Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF532124207 for <quic@ietf.org>; Mon, 5 Mar 2018 04:20:20 -0800 (PST)
Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w25CKJEm026462 for <quic@ietf.org>; Mon, 5 Mar 2018 12:20:19 GMT
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0361.001; Mon, 5 Mar 2018 12:20:19 +0000
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: IETF QUIC WG <quic@ietf.org>
Subject: HTTP/QUIC GOAWAY when there is no client request?
Thread-Topic: HTTP/QUIC GOAWAY when there is no client request?
Thread-Index: AdO0ejjEIYl/lHjWRr238wQqrZNEsg==
Date: Mon, 05 Mar 2018 12:20:17 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAE6341@bgb01xud1012>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.211]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23700.006
x-tm-as-result: No--18.250300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BAE6341bgb01xud1012_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/blG8GTEJw-Grpe9pbRuy63GMqlo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2018 12:20:22 -0000

Hi,

Reading section 4.2.7 of draft-ietf-quic-http-09, it says:

   The GOAWAY frame does not define any flags, and the payload is a QUIC
   Stream ID for a client-initiated, bidirectional stream encoded as a
   variable-length integer.

Steam 0 is the first client-initiated, bidirectional stream. However, it is reserved for the transport's cryptographic operations.

So how would you handle a client that opens a connection but delays sending requests (for some reason)?

Regards
Lucas

P.S

While I'm here, section 4.2.7 later says:


   An endpoint MAY send multiple GOAWAY frames if circumstances change.

   For instance, an endpoint that sends GOAWAY without an error code

   during graceful shutdown could subsequently encounter an error

   condition.


Is this reference to "an error code" supposed to be in relation to CONNECTION_CLOSE or APPLICATION_CLOSE, or is it a hangover from some older version of GOAWAY?