Re: FIN + RST behavior

Martin Thomson <martin.thomson@gmail.com> Thu, 23 March 2017 11:04 UTC

Return-Path: <martin.thomson@gmail.com>
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 5F9CB131589 for <quic@ietfa.amsl.com>; Thu, 23 Mar 2017 04:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rjLiO2UTDYjD for <quic@ietfa.amsl.com>; Thu, 23 Mar 2017 04:04:51 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 917D613158B for <quic@ietf.org>; Thu, 23 Mar 2017 04:04:47 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id y76so176467312qkb.0 for <quic@ietf.org>; Thu, 23 Mar 2017 04:04:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=22sNuSbGLXrWGPFZn8VOnKDgvMnVX0SZma7zMqEl+AI=; b=T+GL+Ay27/ZZ4gcf1+7shilPeCO2QsB6oReLbbnBFgnGaEVwEbm9JSWoZ9fPlavTun 0osiZI4pNNQrJu4ISpXiEzAamvDbK7CBU6SUnU5L/PnXWtXsBLQTDeclaKUiyc6Jmk1L QGK/hE0zLIbhJLjJw4jHLG/2YZL7+8FJQ6U1Bj7pfCmp9uFwkFSeijGq1xXFnsI6fNTL bW/xl9m4RKkyTy9yW4Es1P4wkVq4ehKOy1crbH6EEo0KDUn+5OK/7oIn1QRDXLqZBDjW ECr4NUNZIY4VGEygny7AzTH2TsnK7rN61Sjk5m7qmSynTYOA7OHH0GWacTr1lD5QqWjR RW2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=22sNuSbGLXrWGPFZn8VOnKDgvMnVX0SZma7zMqEl+AI=; b=nc7g7oYdQhI9QuNn93GgYCUD9e/j40c85u4NEL7FObL/TYiiUhNGh4fLipdyfx8jFn cRLKgo8AuceStBDCN8wBoZNwEsA8p12idL6lei/ZBqXQbSiYRkwLGA3y01iFisTHxDnG xaTIJB89lSdl4iSiy/MD04g5f6NQ9KGXhqaB6gVFYQHJLfpj2ejVGGSDl+toVms7Qzmw rmIIMgK3U28TarDMdUDEY/gWouzc4ujLYcjFRs9vHGg4GIpv28kt6gbXZ57bf7TBtEXx j54u/idRCVVB7IJ1Vl+GKGB6VAGB4SkTI5Kv+YgIXHSlLNegmP7BarAkdc+DQHWRmvZN m0hw==
X-Gm-Message-State: AFeK/H0g5IfdNoP7Ke58qos0zkP4h52dT6iqSbE3r8/r4QSUpQLe5hZcuH7m5korXLfZDolDcjbgKj2vpDT17A==
X-Received: by 10.55.122.134 with SMTP id v128mr1442139qkc.115.1490267086703; Thu, 23 Mar 2017 04:04:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.27.194 with HTTP; Thu, 23 Mar 2017 04:04:46 -0700 (PDT)
In-Reply-To: <MWHPR15MB145521D729498455F923679EB63F0@MWHPR15MB1455.namprd15.prod.outlook.com>
References: <MWHPR15MB1455B5E6D4F4FAC8411927E4B63C0@MWHPR15MB1455.namprd15.prod.outlook.com> <CABkgnnVRo_mT7sPO=xvmMdS-6wAJoSpARp+FG1R8i-RQWqE8Lg@mail.gmail.com> <MWHPR15MB145521D729498455F923679EB63F0@MWHPR15MB1455.namprd15.prod.outlook.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 23 Mar 2017 22:04:46 +1100
Message-ID: <CABkgnnVZCp8QBVPe81_9=JsrsAYLpy2KkWtfgY9pWcspoKBMSw@mail.gmail.com>
Subject: Re: FIN + RST behavior
To: Subodh Iyengar <subodh@fb.com>
Cc: "quic@ietf.org" <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/fAauBUQNVpPdB3Whamo8mjtG7_k>
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: Thu, 23 Mar 2017 11:04:53 -0000

On 23 March 2017 at 15:10, Subodh Iyengar <subodh@fb.com> wrote:
> How does the client know when the server has released a slot in it's
> concurrency limit? The server can't immediately release this when it sends
> out the FIN because it still must keep state until it receives all the
> ACKs for the stream. I think the client need to keep track of the ACK of the
> ACKs of all the server sent bytes in the stream, which would be a bit sad.


The client can consider its own resources to be available for use by
the server as soon as it receives the FIN and processes it.  If this
were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.