Re: GOAWAY clarification

Martin Thomson <martin.thomson@gmail.com> Sat, 21 March 2015 16:40 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E2C1A016C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 21 Mar 2015 09:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.012
X-Spam-Level:
X-Spam-Status: No, score=-7.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 XuaMhilBr8hD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 21 Mar 2015 09:40:20 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593181A01F9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 21 Mar 2015 09:40:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YZMNr-0002Xc-RW for ietf-http-wg-dist@listhub.w3.org; Sat, 21 Mar 2015 16:36:23 +0000
Resent-Date: Sat, 21 Mar 2015 16:36:23 +0000
Resent-Message-Id: <E1YZMNr-0002Xc-RW@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1YZMNg-0002W2-Ct for ietf-http-wg@listhub.w3.org; Sat, 21 Mar 2015 16:36:12 +0000
Received: from mail-ob0-f174.google.com ([209.85.214.174]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1YZMNf-0001bb-8Z for ietf-http-wg@w3.org; Sat, 21 Mar 2015 16:36:12 +0000
Received: by obcjt1 with SMTP id jt1so77264140obc.2 for <ietf-http-wg@w3.org>; Sat, 21 Mar 2015 09:35:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Aygqeult6S6ZezUXGP4yhmZnTftzBIzegQiWqFBTNn4=; b=H/wZ3pzp1MG9SBsqPmZsXCMpyOoBiq2IVahD48IvkD+jkiCIsZtRQt6xcVQNm+pvig i7TGIMHJl2MFJ2pkNjEv7QXmYdo1klhUHUT1uwiwU9Jps3WuH0uGfYk1J4dmSvqFqXvU GPSUdQFvFm56k+uggB6UJE0z7s2Y6jf8Cx5KzsEnwi7QKuiSrhuH8fp0xB0ZXPA1lVOT pphfmgoZtCBNTcor9aEbuqMgCB4P3PbQWiJNtjhaJZkwUmlf5axQJ/L9lw5E/+eARW3x 8aiXnloVrljgVtLR+B/T1sK07AWSGSAGZBeAlqr3o8xUA008t0SOtLJyXAE9O1GzDrVY IaHQ==
MIME-Version: 1.0
X-Received: by 10.182.210.197 with SMTP id mw5mr70392335obc.26.1426955745538; Sat, 21 Mar 2015 09:35:45 -0700 (PDT)
Received: by 10.202.48.151 with HTTP; Sat, 21 Mar 2015 09:35:45 -0700 (PDT)
In-Reply-To: <550D19DB.80306@treenet.co.nz>
References: <CABkgnnWrZpNjLnQ2mn0YnoU-e1oArWVDmBTqiX=cDAeeA+ZZ+Q@mail.gmail.com> <550D19DB.80306@treenet.co.nz>
Date: Sat, 21 Mar 2015 09:35:45 -0700
Message-ID: <CABkgnnXg1uV9AP-fgsMzRyY_71ke31sYYknV+TYbJhiEf1qY0Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.214.174; envelope-from=martin.thomson@gmail.com; helo=mail-ob0-f174.google.com
X-W3C-Hub-Spam-Status: No, score=-6.4
X-W3C-Hub-Spam-Report: AWL=0.398, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1YZMNf-0001bb-8Z 639d8f032f87981d099ce52288c0d0cd
X-Original-To: ietf-http-wg@w3.org
Subject: Re: GOAWAY clarification
Archived-At: <http://www.w3.org/mid/CABkgnnXg1uV9AP-fgsMzRyY_71ke31sYYknV+TYbJhiEf1qY0Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29005
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

It would be easy to deal with your concern by having the receiver of
the GOAWAY reply with their own.  I think that avoids all of the
problems you indicate.

On 21 March 2015 at 00:12, Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 21/03/2015 6:53 p.m., Martin Thomson wrote:
>> This seems right to me...
>>
>> @ https://github.com/http2/http2-spec/issues/731
>> ---
>> We are working on a HTTP/2 library and we are a bit confused and we
>> would like to get it right. That's why I am kindly asking for you to
>> answer the following question:
>>
>> Is it correct that after a sender sent a GOAWAY frame with some last
>> stream identifier to a receiver, the sender may still open new
>> streams, even with stream identifiers higher than the last stream
>> identifier sent in the GOAWAY frame? That is the GOAWAY frame and the
>> last stream identifier only limit the ability of the receiver?
>>
>> If this is correct, and I believe it is, then the I find the following
>> sentence in the first paragraph at 6.8 GOAWAY confusing.
>>
>>     Once sent, the sender will ignore frames sent on any new streams
>> with identifiers higher than the included last stream identifier.
>>
>
> Translation: "go away, Im ignoring *all* future streams after N"
>
>> In my opinion it should say something of the like
>>
>>     Once sent, the sender will ignore frames sent on any new streams
>> created by the receiver with identifiers higher than the included last
>> stream identifier.
>
> Translation: "I am going to ignore you now while I continue making new
> streams to fill your pipe ..."
>
> The behaviour is very different and IMHO the proposal allows senders to
> violate the intent of the GOAWAY.
>
>>
>> Thank you very much!
>> ---
>>
>> After all, the purpose is to create a synchronization point for
>> streams created by a peer, marking some set of them as safe to retry.
>> There is little value in delineating streams created by the sender of
>> GOAWAY.
>
> Yes, however one must take into account what type of action the
> synchronisation was done for / is signalling.
>
> Its pretty clear that the intent of the GOAWAY is to signal connection
> closure gracefully. There is no sense in starting new streams after
> having told the other end you are about to *terminate the connection*.
>
>>
>> That has some ramifications, that I'm sure everyone is already aware
>> of: a server that has decided to process a client frame might
>> reasonably initiate server push after sending GOAWAY.  Equally, a
>> client might hang around after GOAWAY and even make more requests, but
>> server pushes would be "ignored".
>
> Currently its a "might" not "must".
>
> If the proposed alteration happens it becomes a must, because until the
> sender of GOAWAY actually completes sending the last possible stream-ID
> from the full set of 2^32-1, the recipient of GOAWAY cant be sure its
> not going to try sending "just one more".
>
>
>>
>> Of course, given that interpretation GOAWAY from a client could be
>> seen as equivalent to SETTINGS_ENABLE_PUSH=0, depending on the value
>> of the last stream ID provided, that is.
>>
>> I'm not sure that these are new ramifications.  The question is
>> whether we want to somehow prevent any aspect of this interpretation.
>> At this extremely late stage in the process that would require
>> something extraordinary, but I offer the opportunity nonetheless.
>>
>
> If a PUSH_PROMISE was sent *before* sending GOAWAY, then the sender is
> free to complete it under the existing semantics.
>
> If it was sent *after* the GOAWAY then the remote end is already in the
> process of discarding state and terminating the connection. There is no
> guarantee that any of it will be handled, so why would a sane sender
> bother wasting bandwidth on new streams it can expect to be dropped?
>
>
> Amos
>