Re: Unidirectional streams PR
Ranjeeth Kumar Dasineni <ranjeeth.dasineni@gmail.com> Tue, 27 June 2017 21:32 UTC
Return-Path: <ranjeeth.dasineni@gmail.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 337511200C5 for <quic@ietfa.amsl.com>; Tue, 27 Jun 2017 14:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iAF7YZdTyMl4 for <quic@ietfa.amsl.com>; Tue, 27 Jun 2017 14:31:59 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 B7C99126CB6 for <quic@ietf.org>; Tue, 27 Jun 2017 14:31:59 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id h134so25576855iof.2 for <quic@ietf.org>; Tue, 27 Jun 2017 14:31:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.107.138.81 with SMTP id m78mr8514868iod.60.1498599118722; Tue, 27 Jun 2017 14:31:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.125.132 with HTTP; Tue, 27 Jun 2017 14:31:38 -0700 (PDT)
In-Reply-To: <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net>
References: <CAN1APdc_ckZu39ZZTETv04iZieogoE_NQCBR-n0jHrC-9dM7Aw@mail.gmail.com> <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net>
From: Ranjeeth Kumar Dasineni <ranjeeth.dasineni@gmail.com>
Date: Tue, 27 Jun 2017 14:31:38 -0700
Message-ID: <CAF4GZgBm7525i2GxiN-Pv66g0WqbDH==fRXN27=7ursNA70w1Q@mail.gmail.com>
Subject: Re: Unidirectional streams PR
To: Christian Huitema <huitema@huitema.net>
Cc: quic@ietf.org
Content-Type: multipart/alternative; boundary="001a113fe80821ddb70552f7ccf4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/IV13ExTO8-tVQ04Mubq2nH4aJjE>
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: 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 process. Cheers, Ranjeeth On Sat, Jun 24, 2017 at 12:15 PM, Christian Huitema <huitema@huitema.net> wrote: > Nice discussion. Seeing this design by many PR, I am afraid we will meet > an old friend: https://en.wikipedia.org/wiki/Camel. > > -- > Christian Huitema > >
- Unidirectional streams PR Martin Thomson
- Re: Unidirectional streams PR Patrick McManus
- Re: Unidirectional streams PR Jo Kulik
- 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 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