Re: [quicwg/base-drafts] Implicitly opened streams add complexity (#896)

Martin Thomson <notifications@github.com> Wed, 25 October 2017 05:58 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405A413B0F4 for <quic-issues@ietfa.amsl.com>; Tue, 24 Oct 2017 22:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.8
X-Spam-Level:
X-Spam-Status: No, score=-9.8 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_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 FSL-yOEdvuqQ for <quic-issues@ietfa.amsl.com>; Tue, 24 Oct 2017 22:58:07 -0700 (PDT)
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709D913915C for <quic-issues@ietf.org>; Tue, 24 Oct 2017 22:58:07 -0700 (PDT)
Date: Tue, 24 Oct 2017 22:58:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1508911086; bh=Adg7JMUQKFDxxlc0s8bhWbhm5F9X3bBA6WZozQYBJ/c=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=n2YJNnKeghHETeKj3dHHAM6wP6QGGvQmP6atAWAByPhfSzOZ5YhnBkIgTy1QmxLyP wJOoyQmpKmCbQU9ri4Fng8q3OgTQteXWVL0u/8zTAIER6+8tQf+CN0WB7vG8dwDdYn 3Kba+e7OGiUst7vI45K4Mu/KH67D73PGul51dNYU=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abff5fc5365d6f8b81cd346b9226555341a1a07f4992cf000000011607e9ee92a169ce0ff4a535@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/896/339223186@github.com>
In-Reply-To: <quicwg/base-drafts/issues/896@github.com>
References: <quicwg/base-drafts/issues/896@github.com>
Subject: Re: [quicwg/base-drafts] Implicitly opened streams add complexity (#896)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59f027ee91341_631a3fc0c7c6af303423b8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/8jd7b6nUzLKaSuEKy2kyCYRuVJg>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Oct 2017 05:58:09 -0000

Here's my take on this, noting that I don't actually care for the complexity, see below:

In-order opening ensures that the passive endpoint (the one not opening streams) isn't surprised.  Ordered opens ensures that it is possible to look at the largest stream ID and the set of open streams and make decisions about what to put in MAX_STREAM_ID.  Without that, you have to account for unopened streams as well or you might be surprised when the opening peer uses all those streams.

We can't enforce in order opening in the general case in the presence of loss.  If two packets are lost containing the frames that open streams X and X + i, the recipient has no way of knowing which packet contained which frame.  And once you get to retransmissions, either could appear first.

That doesn't help a great deal with implicit opening.  The reason that I think we have implicit open is largely as a consequence of being able to assume in order opening.  If X+3i opens, then you can safely assume that you just missed the packets for X+2i and proceed on that basis.  It might be that the endpoint can perform resource allocations, and bump MAX_STREAM_DATA based on its new understanding of what streams are in use. 

I tend to see implicit opens as not being absolutely necessary, but rather creating an incentive to use streams in order.

In most protocols, there's not a lot you can do with an implicitly opened stream, but @ekr shared an example of one protocol that can use the information.

I think that @ekr's point about opening as a distinct action from the transmission of data is an interesting one that we should consider separately.  As much as I love huge-ball-of-string protocol engineering, it seems like we can make a decision about the use case without drawing all this mess into the discussion.  In the general case we don't want to rely on implicit signals for that, though it seems reasonable to allow implicit signals to be used in the event that we decide to retain the idea of implicit open.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/896#issuecomment-339223186