Implicitly opened streams and exposing stream IDs
Marten Seemann <martenseemann@gmail.com> Mon, 02 April 2018 11:43 UTC
Return-Path: <martenseemann@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 68CDC126BF7 for <quic@ietfa.amsl.com>; Mon, 2 Apr 2018 04:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 m8BfmbkQmBbn for <quic@ietfa.amsl.com>; Mon, 2 Apr 2018 04:43:35 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 AB0BD124D37 for <quic@ietf.org>; Mon, 2 Apr 2018 04:43:35 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id v13so17617456iob.6 for <quic@ietf.org>; Mon, 02 Apr 2018 04:43:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VSlU97dst+gJDVGf4GJnJnIb0BW2Zfp0vdQ7zB4CzW0=; b=JjBautpKN4MThiBANOS6N9eyI2FDxZFEZsBSHR8SbcuNohIwzeeDLQg5X9jWbDKbna d6XIcCD2PYugdb9ahpZ7cXlmSmg2Ag/3hcaaeB9nN6hzfQZtNPxoicQ5xoaZNT3iQImm 6YnD4pm8NYyaM4ADtgCB31y2w9zTdF+z+pWhvatgzgppkYDPSUeV41XpcJFVDqywX1zH lwVask5sX1QgASKzDPzvOC2Ye07Gf10givRjdNWNgTCUN1GYcSJKc8nAsV11fQFIQvOt v71C+g14pIMbyz+PdK1W43+OA2+ZeADKRsDigkLpM2yEwNnNwfdPtCvJQh0+bTjevek6 EaMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VSlU97dst+gJDVGf4GJnJnIb0BW2Zfp0vdQ7zB4CzW0=; b=pmqG0Q2zk7mL3I+Hvu8XLcAdKSlc2GB183KSHdWQruagFfE8h81djYn6zDAyCrAruN EaHLHsLiqUWz9GLAFPHXOZ1SPj/dbGJhvnTdmhOsEBezirLvQNOHCuoBxLcl0Eu8sGyL F/rHH4IZ17bfZDzEGLB7xVkwU9hcUqiH+P784R77bewGwk2CH+3R3W4+BPTUJw1AKYPw v0i+em8TRUA01qVKDGseFpDXRophWK6l4FZUzCW5orR0ha6qrXESlJlP2WZa6+Vo5FO2 tIjpDCrcc6i5Wp321xLhLFY+2EfGI35OZ/E2IxevYWyaoMfsqMTWJaqgkaeE/YtmzJ+R NmLw==
X-Gm-Message-State: AElRT7F2WzZk9ZOWkkoyxGqlbJtjV7lxZ5CXYPAUEXq8yD4Ji1eEzNt4 S+YLDD7b1OMOGTQc57FbhfYE4UX1cjPDWE5gME00FA==
X-Google-Smtp-Source: AIpwx4/K2OzArZ6OLmUuo19CD/AO5t4sue50QrpClPphtNwLnHiyxu1oTvKHtqJbxxRblQlG68w1fcsjw+i3fWojSwU=
X-Received: by 10.107.6.32 with SMTP id 32mr8366830iog.24.1522669414636; Mon, 02 Apr 2018 04:43:34 -0700 (PDT)
MIME-Version: 1.0
From: Marten Seemann <martenseemann@gmail.com>
Date: Mon, 02 Apr 2018 11:43:23 +0000
Message-ID: <CAOYVs2qp3L-dTdFfBNDQT0Q=nCu+6Ew3gmF=0GMS2vVw1JfWCg@mail.gmail.com>
Subject: Implicitly opened streams and exposing stream IDs
To: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a113fbf5c91e1b10568dc19a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/a2NzdCILLGqJPsn-NS4L4cQCKZ0>
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: Mon, 02 Apr 2018 11:43:37 -0000
Recently, the implicit opening of streams (i.e. that when a receiver receives a frame for stream N+4, it can assume that stream N was already opened, but the packet might have been reordered) was removed from the draft. I think this change has some consequences that we haven't discussed so far. For the purpose of writing some pseudocode, I'm assuming a QUIC API that provides an *AcceptStream()* method, but the conclusions will be the same for a callback-based API. - If QUIC has implicit stream opening, *AcceptStream()* would return the streams in order (and if a frame opening stream N+4 is received before stream n is opened, *AcceptStream()* will first return stream N and then stream N+4). - Without implicit stream opening, *AcceptStream()* just returns whatever stream is received first. Streams might be returned in arbitrary order, if the peer doesn't open streams consecutively or if packets are reordered. Now imagine an application protocol where the first unidirectional stream opened by the client is a control stream, and all higher unidirectional streams are data streams. The application on the server side needs to find out which stream is the control stream, because it needs to be handled separately. With implicit stream opening, the server code would be: control_stream = AcceptStream() // is guaranteed to open the first stream // handle the control stream while true: stream = AcceptStream() // handle the data stream and without implicit stream opening: while true: stream = AcceptStream() if stream.ID() == kControlStreamID: // handle the control stream else: // handle the data stream In this case, after accepting a stream, we first have to check the stream ID, since there's no guarantee if the control stream will actually be received first. For this stream mapping, it seems like the removal of implicitly opened streams implies that QUIC has to expose stream IDs to the application layer. I'm not sure if this was intended when making the change, especially since we're considering to change HQ such that it doesn't rely on QUIC stream IDs any more. We only manage to avoid the problem described here in our HTTP mapping, because the HTTP control streams are unidirectional and the request streams are bidirectional, and can therefore be told apart by their directionality. However, as a general transport protocol, other applications built on top of QUIC will have to find some way to deal with it.
- Implicitly opened streams and exposing stream IDs Marten Seemann
- RE: Implicitly opened streams and exposing stream… Lucas Pardue
- RE: Implicitly opened streams and exposing stream… Mikkel Fahnøe Jørgensen
- Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
- Re: Implicitly opened streams and exposing stream… Marten Seemann
- Re: Implicitly opened streams and exposing stream… Martin Thomson
- Re: Implicitly opened streams and exposing stream… Mikkel Fahnøe Jørgensen
- Re: Implicitly opened streams and exposing stream… Marten Seemann
- Re: Implicitly opened streams and exposing stream… Martin Thomson
- Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
- RE: Implicitly opened streams and exposing stream… Nick Banks
- Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
- Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
- RE: Implicitly opened streams and exposing stream… Nick Banks
- RE: Implicitly opened streams and exposing stream… Nick Banks
- Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
- Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
- Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov
- Re: Implicitly opened streams and exposing stream… Ian Swett
- RE: Implicitly opened streams and exposing stream… Lubashev, Igor
- Re: Implicitly opened streams and exposing stream… Marten Seemann
- RE: Implicitly opened streams and exposing stream… Lubashev, Igor
- RE: Implicitly opened streams and exposing stream… Lubashev, Igor
- Re: Implicitly opened streams and exposing stream… Dmitri Tikhonov