Re: Unidirectional streams PR

Ranjeeth Kumar Dasineni <> Tue, 27 June 2017 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 337511200C5 for <>; Tue, 27 Jun 2017 14:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iAF7YZdTyMl4 for <>; Tue, 27 Jun 2017 14:31:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7C99126CB6 for <>; Tue, 27 Jun 2017 14:31:59 -0700 (PDT)
Received: by with SMTP id h134so25576855iof.2 for <>; Tue, 27 Jun 2017 14:31:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vUvHu7ysGRa2bRdP1ubMcBSj9o9DoOErZXWNYe78x0c=; b=OuSLKFJuE9GWjFyXJ6WTUs0nFOqlI9q3tNn9FM4lcMnnOAl2mHlHtMKOKEgqqwk+bu x6IrgyJaHI7Jx3sJSse4c4CEM10B9n8ND+ermsLNk9/68e1H3YS2zp3bRhbYUD0h7xmF H+Oz5MS0zLyy5W9pPh2k6T3OLeL4smASY2wFhZpLZ7qdRif2f3BMVV5TRdu8uhdXLKLz XmM2RTdLK19S9W/ppFEUT3V1fj78hYr4lX8yIkM7hZNpjbbced6VDorZpPLm4BT4ONVI 8aEh5dxbPzCWdh8PqwZ9dpFt9MB65DkWtAsw9TmLjhPIR8YYaJjbNzZYrdvprNNxb9fZ C/bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vUvHu7ysGRa2bRdP1ubMcBSj9o9DoOErZXWNYe78x0c=; b=bT1ybVFgNIxeOhRQL+RwGlSVhXHxtnYWgGOzBW/twWl59bcdtpLav1/3BuN153GZOX g4xONB89H8B7aXz2qIsnoElbfrNcZfJo0i33g4uB1VTg69T1XYmQmsur6OQNYxPzN10E 6s1rKr+2g9m8MwZnQumXztIObuibv86eEN6jAk1qvs5s7u1cpAOQ6YM6nZAuOQ33m9Ne RarIwlM/r7RYFksi8CU2vn6UobkBFcCF3GfiOxTPs5ABo82JeefcaX2fk4A6RnApzNSl 8L7i4PQ2l3kN0LIP14ard6id4QItzTfWWfIl+w3/PxMV+vc1ztnd/QCy2BxUo3Cw+S1l ETKg==
X-Gm-Message-State: AKS2vOz2RWT0a5Kpf0PDmhs0+6faCGApLhUAYqiGS7bzBgxCE+PNvu/n cUP2sQyl7yywYJAKF9EBd+OD+YwB1Q==
X-Received: by with SMTP id m78mr8514868iod.60.1498599118722; Tue, 27 Jun 2017 14:31:58 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 27 Jun 2017 14:31:38 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Ranjeeth Kumar Dasineni <>
Date: Tue, 27 Jun 2017 14:31:38 -0700
Message-ID: <>
Subject: Re: Unidirectional streams PR
To: Christian Huitema <>
Content-Type: multipart/alternative; boundary="001a113fe80821ddb70552f7ccf4"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Jun 2017 21:32:02 -0000

This thread has gone quiet. So, I am voicing my concerns about Martin's
proposal here to reiterate the importance of deployment experience, making
things no simpler than necessary and to generally evoke a sense of urgency.
Personal opinions, of course!!

1. We are the underplaying the importance of deployment experience. I am
afraid that IETF-QUIC, after these changes, diverges quite far from the
deployed G-QUIC. Far enough, to throw serious doubt on all assumptions
about performance and deployability. It becomes effectively a brand new
protocol designed not based on running code but what seems to be an obvious
simplification of one layer, at the cost of complexity at another layer.
Leaving the benefits of simplification aside, I am wary of standardizing
things that have not been deployed anywhere. H2 push and priorities should
serve as a lesson here where one could clearly articulate the benefits when
designing them and yet it was extremely hard to realize those benefits in
practice. Here, I have a hard time even articulating the benefits of a
simple transport layer, speaking of which ...

2. We are overplaying the simplicity of design. Even if we deem deployment
experience not a concern, if every application layer protocol that needs
support for bidirectional streams has to implement some correlators and
such above, that's a net negative in terms of complexity. Arguably, it's
far simpler for an application to simulate/enforce unidirectionality when
it needs. Not to mention there does not seem a deployed application or an
immediate candidate that needs it. H2 Push is a special pony which is yet
to be deployed widely and something that I would treat as an exception, not
norm. Even with H2, where implementation of application level correlators
seems simple enough, it raises the questions on ease of deployment (if
proxies will get this right), debuggability (examining a single request +
response is now harder) and the impact of bug (more prone to sending
critical data to the wrong destination). The demonstrated success of G-QUIC
and the first likely role for IETF-QUIC is as an approximately drop-in
replacement for H2. I would like the focus to be on succeeding there first
before attempting to build an overly generic transport protocol. Which
leads me to ...

3. QUIC is not the last transport that will be built. Not to speak of
future versions of QUIC itself. Part of the allure of moving transport to
user space, to me, is the ability to iterate faster. The success of H2 and
the wide interest in QUIC convinces me that protocols will evolve at a much
faster rate going forward. And that there will be enough time and
opportunities to experiment as more applications use QUIC and evolve a
different set of needs. Such experiments and implementation experience
should drive the changes, I believe. Having said that, some ideas in the PR
(like the explicit type field in stream header and the push id) are not
really tied to unidirectionality and I would like to see them absorbed into
IETF-QUIC anyway.

This is my first mail to the working group. My biggest motivation was to
reiterate on the sense of urgency. Pardon me if I flouted any rules in the


On Sat, Jun 24, 2017 at 12:15 PM, Christian Huitema <>

> Nice discussion. Seeing this design by many PR, I am afraid we will meet
> an old friend:
> --
> Christian Huitema