Re: Unidirectional streams PR

Christian Huitema <huitema@huitema.net> Thu, 29 June 2017 16:35 UTC

Return-Path: <huitema@huitema.net>
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 34AAA12EC49 for <quic@ietfa.amsl.com>; Thu, 29 Jun 2017 09:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ETRTqava51zg for <quic@ietfa.amsl.com>; Thu, 29 Jun 2017 09:35:10 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B2A124E15 for <quic@ietf.org>; Thu, 29 Jun 2017 09:35:10 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1dQcPM-0004NC-EA for quic@ietf.org; Thu, 29 Jun 2017 18:35:09 +0200
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1dQcPF-0002wy-UT for quic@ietf.org; Thu, 29 Jun 2017 12:35:06 -0400
Received: (qmail 27781 invoked from network); 29 Jun 2017 16:35:00 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.244]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 29 Jun 2017 16:35:00 -0000
To: quic@ietf.org
References: <CAN1APdc_ckZu39ZZTETv04iZieogoE_NQCBR-n0jHrC-9dM7Aw@mail.gmail.com> <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <CAF4GZgBm7525i2GxiN-Pv66g0WqbDH==fRXN27=7ursNA70w1Q@mail.gmail.com> <20170628124221.GA15608@ubuntu-dmitri> <CAN1APdc3YO4-FEc6C--PzFGxzQiAUeBZ96HkjtjS1RR0qigrzw@mail.gmail.com> <CAE=ybzNtSZx9-bj9-n-ieLMB=YvJCjCExugvA3_JPVrdEEqK9A@mail.gmail.com> <DB5PR07MB123748F2AB7374DAC0CC9E1484DD0@DB5PR07MB1237.eurprd07.prod.outlook.com> <MWHPR21MB0141BD23011EB26F882C864787DD0@MWHPR21MB0141.namprd21.prod.outlook.com> <CABkgnnXEq9-jxedU_Rmi4XQ+t0SNUOAMbyWXcnhyLKz+OzP2CQ@mail.gmail.com> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> <CAKcm_gMb9PkBKhTRF3ue2KGgwHgKN8rsanD8rqqr_wUFJ3GNZQ@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net>
Date: Thu, 29 Jun 2017 09:34:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAKcm_gMb9PkBKhTRF3ue2KGgwHgKN8rsanD8rqqr_wUFJ3GNZQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------770AB73FAD11E52838B95C5B"
Subject: Re: Unidirectional streams PR
X-Originating-IP: 168.144.250.232
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.20)
X-Recommended-Action: accept
X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJackVDEeh/s63C3hq8BP19aND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23gyy/6QOlnqqnVP+erb63jz1ArgeOpTMAnrdw QOeVZolmW+kLkdxBnHUv18zBlWQxYOEkjsX7F8KmpUaZQHV+ST61TfxIvi8LwOTvVrRIhaC2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpIuW2VxLnS94njDgTNmyTXH6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGySJ1NAlehadpd7FIhnvRSGveNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17jczFy7tELlDUkEnE2lik8C2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe91Y2lWQ2MJXd3CnOcfuxlrTMLn6MURQGfriekzS 9Ga3AA==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/1MaZclZnNHxjgiCg5eBdBxXO4sA>
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, 29 Jun 2017 16:35:12 -0000

On 6/28/2017 6:23 PM, Ian Swett wrote:

> I updated my PR(#656 <https://github.com/quicwg/base-drafts/pull/656>)
> today, sorry for the delay.  I attempted to address the issues
> identified with text.  Some may prefer more tweaks to the state
> diagram, which are also possible, so I'm open to suggestions.
>
> In the meantime, I've been considering other alternatives, including
> variations on Mike's direction and a variation of the "Do Nothing"
> option which involved the application signaling to the transport that
> streams of a certain sort(ie: server to client for server push) were
> unidirectional, as GQUIC does today.  Overall, I think the approach
> I've outlined does a good job of iterating on existing deployment
> experience and adding explicit signaling for unidirectional streams
> instead of implicit signaling at the application layer.  There are
> pros and cons to both explicit and implicit signaling, but I think
> explicit signaling is more complete and less prone to application error.
>

I understand how to handle concurrent stream limits with plain
bidirectional streams or with plain unidirectional streams, but things
are not so clear when we start mixing models by adding a unidirectional
option to bidirectional or vice versa. In the clean models, we can count
the number of streams initiated by one entity and not yet closed. But in
the mixed models, what do we count, exactly?

For example, let's suppose that in an unidirectional stream model, the
client creates a stream that also "implies" a stream creation in the
other direction. Does this implied stream count against the server limit
or the client limit?

Or vice versa. Suppose that in a bidirectional stream model the client
creates a stream that is declared as actually unidirectional. And
suppose that this stream is immediately closed -- a stream frame with
both the FIN bit and the PR 656 UNI bit set. This stream counts against
the client's number of concurrent streams, but it is immediately closed
by both parties. Does it count as zero?
-- 

Christian Huitema