IETF Logo Mail Archive

RE: FIN + RST behavior

"Lubashev, Igor" <ilubashe@akamai.com> Thu, 23 March 2017 18:27 UTC

Return-Path: <ilubashe@akamai.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 94DE2129B5D for <quic@ietfa.amsl.com>; Thu, 23 Mar 2017 11:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 C5rb_JqHFpHo for <quic@ietfa.amsl.com>; Thu, 23 Mar 2017 11:27:31 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id B40381315FE for <quic@ietf.org>; Thu, 23 Mar 2017 11:27:31 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3AA4843343C; Thu, 23 Mar 2017 18:27:31 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2433143340A; Thu, 23 Mar 2017 18:27:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1490293651; bh=FHtNWHYb7PqLGdykfh1GD1ZrffghTJDqRMFbA2h8VU8=; l=13493; h=From:To:CC:Date:References:In-Reply-To:From; b=Hwmx/A2GT2KNRC0svY6i86rbK3y0vTnoBpMIr3jy9cqXkD5V0uZfCkcpcezj+9UJz hGydwvY9fPDFOwbFN4Ikjd7tnlGTevnG53goFxWT4rEeYUJRwRHSHKFyHkszPQO2bP TJuxRrwZk42kwodCEr1xR0trYT2bwiew2wMjD4C0=
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1EFD11FC8B; Thu, 23 Mar 2017 18:27:31 +0000 (GMT)
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 23 Mar 2017 14:27:30 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 23 Mar 2017 14:27:30 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Thu, 23 Mar 2017 14:27:30 -0400
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Subodh Iyengar <subodh@fb.com>, Martin Thomson <martin.thomson@gmail.com>
CC: "quic@ietf.org" <quic@ietf.org>
Subject: RE: FIN + RST behavior
Thread-Topic: FIN + RST behavior
Thread-Index: AQHSo1zPcZTZN/tlZkuJR+NHZURtjKGh2eCAgAA5O4CAAHPJAIAAZdGA///G0xA=
Date: Thu, 23 Mar 2017 18:27:29 +0000
Message-ID: <8dde9f5fac4440a8ac6c04e27efc042f@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <MWHPR15MB1455B5E6D4F4FAC8411927E4B63C0@MWHPR15MB1455.namprd15.prod.outlook.com> <CABkgnnVRo_mT7sPO=xvmMdS-6wAJoSpARp+FG1R8i-RQWqE8Lg@mail.gmail.com> <MWHPR15MB145521D729498455F923679EB63F0@MWHPR15MB1455.namprd15.prod.outlook.com>, <CABkgnnVZCp8QBVPe81_9=JsrsAYLpy2KkWtfgY9pWcspoKBMSw@mail.gmail.com> <MWHPR15MB1455956FFF7AB6730C1E345CB63F0@MWHPR15MB1455.namprd15.prod.outlook.com>
In-Reply-To: <MWHPR15MB1455956FFF7AB6730C1E345CB63F0@MWHPR15MB1455.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.234]
Content-Type: multipart/alternative; boundary="_000_8dde9f5fac4440a8ac6c04e27efc042fusma1exdag1mb5msgcorpak_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hkQ7vdsBMjP1nULZ8Zmm2fq5yE0>
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 18:27:34 -0000

Concurrency limit is about the amount of local resources a remote peer can consume.  It is not about how much local resources can be consumed by the local application - these limits can be enforced without any help from the protocol.

So concurrency limit is really the number of concurrent in-progress streams that a peer is willing to receive.  This maps well with unidirectional streams, but this is not a requirement.  To be put precisely, the concurrency limit can be defined as "the max number of streams with non-zero unACKed bytes sent by that peer".  This means, peers can negotiate separate concurrency limits.


-          Igor

From: Subodh Iyengar [mailto:subodh@fb.com]
Sent: Thursday, March 23, 2017 1:09 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior


>  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.

Ya in the case of the previous example, it is a server resource since it's a client initiated stream.
@Martin Thomson<mailto:martin.thomson@gmail.com> I'm starting to like your proposal of unidirectional streams more and more :)



Subodh



________________________________
From: QUIC <quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>> on behalf of Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>
Sent: Thursday, March 23, 2017 4:04:46 AM
To: Subodh Iyengar
Cc: quic@ietf.org<mailto:quic@ietf.org>
Subject: Re: FIN + RST behavior

On 23 March 2017 at 15:10, Subodh Iyengar <subodh@fb.com<mailto: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.

v2.23.0 | Report a Bug | By Email