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