Re: Unidirectional streams PR
Jana Iyengar <jri@google.com> Fri, 23 June 2017 01:25 UTC
Return-Path: <jri@google.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 077E9129B9B for <quic@ietfa.amsl.com>; Thu, 22 Jun 2017 18:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 (2048-bit key) header.d=google.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 FA_EQ23Tt0PG for <quic@ietfa.amsl.com>; Thu, 22 Jun 2017 18:25:42 -0700 (PDT)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 40A87126DFB for <quic@ietf.org>; Thu, 22 Jun 2017 18:25:42 -0700 (PDT)
Received: by mail-pg0-x22b.google.com with SMTP id e187so14971954pgc.1 for <quic@ietf.org>; Thu, 22 Jun 2017 18:25:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lbym2AV7tYCU+u9wTwnQm1qFukhFBVqHst7X1w4K/hQ=; b=R7F5GhgDiZGujzLkx056pLYC4ZywMXenW6HtbZjLHEk04/c9jM7X9oCWh910BCoHjo RU++ko6xV22kkBIuQirTCwDvwgmZ0H7K6/GuwXzJcus2QNykMabyXMvy91JAgJptOoSl q16eanYkIj4YKqHqkemCtVBCzAywLfr5W/YZYEnRoB/+Z7MPpNUGSpmzl7DJwDtE+6QW NltBRgmrmmrS/9tCEXmhsaszijXiZ8ULH4usKn2+mXBaCTM5oLlHZk5z8EoBRJiNWUJR CkLWrPY3xntoHQ3n0XFymwJEvZNwoDmk6xFauSpIZUfDBsiC3cAgKWtsnjJlU5O+dvMh Y9Hw==
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=lbym2AV7tYCU+u9wTwnQm1qFukhFBVqHst7X1w4K/hQ=; b=eZOaaLHtDWvjRYdIyNzVCgKPTpBtYJfwhpqyswD7hga5P32z1MmGz/qSy0f+kdhM4E aEpy3f7ZyrPAWYgKXhdBoERpG2UmcUmWqWMHGoPXglEjBwqGhZT1qnyIO0AJO39c/EwC rnrXveAs1hYEoRZ9LUgnDKB56fVIH7QNIbzIVy/5wLj2dGG096RO62MPyYTdGmAG9iej pS7nIEgcv1NowbXSyHiA+K/eb/B4LWVydljSlfP6qSp0eWu59+75Ygb3u+UeuOJZ2hLJ /k6ZZlooE6F/tS/fhJmCXGv6CCADyywKKoCxP6HpH2kKalvWYTcv4IxXEkt6Dy/pkyyU /8iQ==
X-Gm-Message-State: AKS2vOym3KMYzoSzDAVjpnwbGPYluH17IiYfiUxwsZe50py00v0/MGQE ovXRIIJx7AIt0vINGyUBLLbLnC64RKD1
X-Received: by 10.99.121.1 with SMTP id u1mr5469977pgc.20.1498181141507; Thu, 22 Jun 2017 18:25:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.179.39 with HTTP; Thu, 22 Jun 2017 18:25:40 -0700 (PDT)
In-Reply-To: <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <CABkgnnW+veDVq27v+wTz0cA=eGPRTLQ1A90A0ynHLPU88Pg77Q@mail.gmail.com> <CAOdDvNpORYBr7+Q8M_nnGOm4MsWqVbm6koOtQ+=An8t7AbccGg@mail.gmail.com> <CAGD1bZb9Na32z=Gg9JS+FzrGGN9Jhw=QDTMTYS=FVcNesoSMig@mail.gmail.com> <CABkgnnV2yPP-qgLKZYPsvawXc7FP4RM7CZDDa7aFaNy0KxLfag@mail.gmail.com> <CA+9kkMCF+wUPA452gYgdG65Y4zNctzGWd4HtZ2Ge70=S9k-_Qw@mail.gmail.com> <CABkgnnU6H+2AeY0n7-d+k0baM7UJ6fuN4PX7ez+KRN17eFg6Yg@mail.gmail.com> <MWHPR21MB0141A7116859D7955C92CC0987DB0@MWHPR21MB0141.namprd21.prod.outlook.com> <349d20e4f7d9458aaf7797d2025b2064@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Jana Iyengar <jri@google.com>
Date: Thu, 22 Jun 2017 18:25:40 -0700
Message-ID: <CAGD1bZbX1gTOh=LpQqLre8qgfB91=JrTCpYExzWMuBPo=V5_eA@mail.gmail.com>
Subject: Re: Unidirectional streams PR
To: "Lubashev, Igor" <ilubashe@akamai.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, Martin Thomson <martin.thomson@gmail.com>, Ted Hardie <ted.ietf@gmail.com>, QUIC WG <quic@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>
Content-Type: multipart/alternative; boundary="94eb2c0ef260c015d80552967ae7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KLXXRDYQ1E5rLeZj8f0dHKFbNmE>
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: Fri, 23 Jun 2017 01:25:45 -0000
On Thu, Jun 22, 2017 at 6:06 PM, Lubashev, Igor <ilubashe@akamai.com> wrote: > I like the idea of unidirectional streams, if they make life easier for > apps -- both "traditional" apps like H2 as well as less usual apps like ssh > (one stream in one direction, two associated streams in the opposite > direction). > > I also like Mike's idea of OPEN_STREAM frame. The way I'd describe > OPEN_STREAM frame is that it is implicitly a STREAM frame with 0-offset and > a set of "per-stream properties". > > An important point is that when Transport is aware of the association of > two unidirectional streams, the Transport API would be able to implement a > bidirectional socket-like abstraction for applications that desire one. > I'm not sure I follow your thinking here: are you suggesting that QUIC implement bidirectional streams in addition to unidirectional streams? - jana > > OPEN_STREAM frame > The type byte for a OPEN_STREAM frame contains embedded flags, and is > formatted as 10FSSPPD. The F, SS, and D bits are parsed as per STREAM frame. > * The PP bits encode the size of the Params Bitmap field. The values 00, > 01, 02, and 03 indicate lengths of 8, 16, 24, and 32 bits long respectively. > > The two Least Significant bits of the Params Bitmap indicate the length of > the Associated Stream ID. The LSB values 00, 01, 02, and 03 indicate > lengths of 0 (none), 8, 16, and 32 bits long respectively. > We can define up to 30 additional bits to be meaningful to the transport. > (I can imagine Partial-Reliability bit, Flow-Control-Exempt bit, > Priority-Delivery (aka "DontBuffer") bit, etc). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stream ID (8/16/24/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Params Bitmap (8/16/24/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Associated Stream ID (0/8/16/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | [Data Length (16)] | Stream Data (*) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note that if Params Bitmap is 0x0, this OPEN_STREAM frame is equivalent to > STREAM frame with OO=0. > > > > -----Original Message----- > From: Mike Bishop [mailto:Michael.Bishop@microsoft.com] > Sent: Thursday, June 22, 2017 6:48 PM > To: Martin Thomson <martin.thomson@gmail.com>; Ted Hardie < > ted.ietf@gmail.com> > Cc: Jana Iyengar <jri@google.com>; QUIC WG <quic@ietf.org>; Patrick > McManus <pmcmanus@mozilla.com> > Subject: RE: Unidirectional streams PR > > I suppose you could drop the stream type header from HTTP into QUIC and > make the types "bidirectional stream," "unidirectional stream," and "mate > of bidirectional stream"; the last would further need to identify which > peer stream it corresponded to. > > But making them the first couple bytes of the stream data feels kind of > kludgy if this is fundamentally built into the transport, which means they > really belong in a dedicated frame. Maybe a dedicated OPEN_STREAM frame, > which blocks any data received on that stream until you know what type it > is? > > Actually, if we're planning on introducing other per-stream properties > like partial reliability, there might be value in an OPEN_STREAM frame > where we can describe a stream's desired properties before any data > flows.... > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Thursday, June 22, 2017 3:32 PM > To: Ted Hardie <ted.ietf@gmail.com> > Cc: Jana Iyengar <jri@google.com>; QUIC WG <quic@ietf.org>; Patrick > McManus <pmcmanus@mozilla.com> > Subject: Re: Unidirectional streams PR > > On 23 June 2017 at 05:15, Ted Hardie <ted.ietf@gmail.com> wrote: > > My personal take on that right answer there is to support both, with > > an explicit signal of when each model is in use, > > I have heard this request now from several folks at Google. I don't know > how to make this work without increasing complexity considerably . I'd be > willing to be wrong about this, but would prefer to see a proposal. I > don't need a fully-worked proposal with text, just a sketch of how the > pieces work in enough detail to understand how this might interact with > other parts of the protocol. I think that Jana offered to do this, so > maybe I can wait for that (c.f., Mark's earlier statement about > priority/urgency). > >
- Unidirectional streams PR Martin Thomson
- Re: Unidirectional streams PR Patrick McManus
- Re: Unidirectional streams PR Jana Iyengar
- Re: Unidirectional streams PR Martin Thomson
- Re: Unidirectional streams PR Jana Iyengar
- Re: Unidirectional streams PR Mark Nottingham
- Re: Unidirectional streams PR Martin Thomson
- Re: Unidirectional streams PR Jana Iyengar
- RE: Unidirectional streams PR Mike Bishop
- RE: Unidirectional streams PR Lucas Pardue
- Re: Unidirectional streams PR Jo Kulik
- Re: Unidirectional streams PR Ian Swett
- Re: Unidirectional streams PR Eric Rescorla
- Re: Unidirectional streams PR Ted Hardie
- Re: Unidirectional streams PR Wenbo Zhu
- Re: Unidirectional streams PR Martin Thomson
- Re: Unidirectional streams PR Ted Hardie
- RE: Unidirectional streams PR Mike Bishop
- Re: Unidirectional streams PR Jana Iyengar
- Re: Unidirectional streams PR Jana Iyengar
- Re: Unidirectional streams PR Ryan Hamilton
- Re: Unidirectional streams PR Martin Thomson
- RE: Unidirectional streams PR Lubashev, Igor
- Re: Unidirectional streams PR Jana Iyengar
- Re: Unidirectional streams PR Ian Swett
- RE: Unidirectional streams PR Lubashev, Igor
- Re: Unidirectional streams PR Ian Swett
- RE: Unidirectional streams PR Lubashev, Igor
- RE: Unidirectional streams PR Mike Bishop
- Re: Unidirectional streams PR Ryan Hamilton
- Re: Unidirectional streams PR Christian Huitema
- RE: Unidirectional streams PR Lubashev, Igor
- RE: Unidirectional streams PR Lubashev, Igor
- Re: Unidirectional streams PR Martin Thomson
- Re: Unidirectional streams PR Philipp S. Tiesel
- Re: Unidirectional streams PR Ian Swett
- RE: Unidirectional streams PR Lubashev, Igor
- Re: Unidirectional streams PR Ian Swett
- RE: Unidirectional streams PR Mike Bishop
- Re: Unidirectional streams PR Mikkel Fahnøe Jørgensen
- Re: Unidirectional streams PR Christian Huitema
- Re: Unidirectional streams PR Ranjeeth Kumar Dasineni
- Re: Unidirectional streams PR Dmitri Tikhonov
- Re: Unidirectional streams PR Mikkel Fahnøe Jørgensen
- Re: Unidirectional streams PR Jo Kulik
- RE: Unidirectional streams PR Swindells, Thomas (Nokia - GB/Cambridge, UK)
- RE: Unidirectional streams PR Mike Bishop
- Re: Unidirectional streams PR Martin Thomson
- RE: Unidirectional streams PR Lubashev, Igor
- Re: Unidirectional streams PR Ian Swett
- Re: Unidirectional streams PR Christian Huitema
- RE: Unidirectional streams PR Mike Bishop
- Re: Unidirectional streams PR Christian Huitema
- Re: Unidirectional streams PR Mikkel Fahnøe Jørgensen
- Re: Unidirectional streams PR Subodh Iyengar
- RE: Unidirectional streams PR Lubashev, Igor
- Re: Unidirectional streams PR Subodh Iyengar
- RE: Unidirectional streams PR Lubashev, Igor
- Re: Unidirectional streams PR Kazuho Oku
- RE: Unidirectional streams PR Lubashev, Igor
- Re: Unidirectional streams PR Subodh Iyengar
- Re: Unidirectional streams PR Kazuho Oku
- Re: Unidirectional streams PR Martin Thomson
- Re: Unidirectional streams PR Kazuho Oku
- Re: Unidirectional streams PR Jana Iyengar
- Re: Unidirectional streams PR Martin Thomson
- Re: Unidirectional streams PR Kazuho Oku
- RE: Unidirectional streams PR Lubashev, Igor
- Re: Unidirectional streams PR Martin Thomson
- Re: Unidirectional streams PR Kazuho Oku
- Re: Unidirectional streams PR Martin Duke
- Re: Unidirectional streams PR Jana Iyengar
- Re: Unidirectional streams PR Martin Duke
- Re: Unidirectional streams PR Jana Iyengar
- RE: Unidirectional streams PR Lubashev, Igor
- RE: Unidirectional streams PR Mikkel Fahnøe Jørgensen
- RE: Unidirectional streams PR Lubashev, Igor
- Re: Unidirectional streams PR Charles 'Buck' Krasic
- Re: Unidirectional streams PR Charles 'Buck' Krasic