RE: Implicitly opened streams and exposing stream IDs

"Lubashev, Igor" <ilubashe@akamai.com> Thu, 05 April 2018 14:06 UTC

Return-Path: <ilubashe@akamai.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 432391289B0 for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 07:06:21 -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, 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=akamai.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 Q-raPelHoB3O for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 07:06:19 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C09D129C6B for <quic@ietf.org>; Thu, 5 Apr 2018 07:06:18 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w35DwmBN028646; Thu, 5 Apr 2018 15:06:16 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=NqnUgb5qiro/psuU9dBEooFHr5fc0SSwRTchYatjmaw=; b=LW1gkUkuS7UtYz4MIeEdKjFYJIuvL1rZ4ArvDMoIqWfhefdTzVebx4o0KCFuu2Y5EjM6 TwSkQbGowNsSxYo+nC9U+CW9+Zu1O4j0sbav9L/m+LVnqLRA3vb8oAgu3qYEhNph448b FpQXYp+2AHOn5TDkEmLKxxExG7Ky/qnu25R7Ao9iXq+CnmkqJ6ccnG80Al9374MmVlk2 GGZmb5GxCX41bhYULLduYsgewvisDzwtms2qZIEwbu5H/g+5SFFZ1Bh8bxxewGSNNNUk Kf3ERz1Zw58PfINNPtqS2gKs3AiZaCwWxNaE+vIn2PKNoef8B6gqCGCCK6nASisXvWA0 0A==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2h4n5g4an5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 15:06:16 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35E2NQg025990; Thu, 5 Apr 2018 10:06:15 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2h25nvtnxj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 10:06:14 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 5 Apr 2018 10:06:13 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1365.000; Thu, 5 Apr 2018 10:06:13 -0400
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: "martenseemann@gmail.com" <martenseemann@gmail.com>
CC: "quic@ietf.org" <quic@ietf.org>
Subject: RE: Implicitly opened streams and exposing stream IDs
Thread-Topic: Implicitly opened streams and exposing stream IDs
Thread-Index: AQHTynfbGUCX+ewXh0mMrL6WkO0VQ6PyGkT0gABNfwD//9HPwg==
Date: Thu, 05 Apr 2018 14:06:12 +0000
Message-ID: <d77eac913ac44ce8a2f96ae38782d3bc@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <CAOYVs2qp3L-dTdFfBNDQT0Q=nCu+6Ew3gmF=0GMS2vVw1JfWCg@mail.gmail.com> <42531619e25b4a4cbd16e77fb1859fde@usma1ex-dag1mb5.msg.corp.akamai.com>, <CAOYVs2p0OvTKCZho9XEDRGEftH_yu+VTKmHraZ_bkrJTBafRwQ@mail.gmail.com>
In-Reply-To: <CAOYVs2p0OvTKCZho9XEDRGEftH_yu+VTKmHraZ_bkrJTBafRwQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_d77eac913ac44ce8a2f96ae38782d3bcusma1exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050148
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=943 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050147
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/TffDlYG93pGpV-Y5_rET2p5PGyg>
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: Thu, 05 Apr 2018 14:06:21 -0000

I agree. I would like to see MUST there as well.

-----Original Message-----
From: Marten Seemann [martenseemann@gmail.com]
Received: Thursday, 05 Apr 2018, 8:51AM
To: Lubashev, Igor [ilubashe@akamai.com]
CC: quic@ietf.org [quic@ietf.org]
Subject: Re: Implicitly opened streams and exposing stream IDs

Hi Igor,

This is exactly the change I'm proposing. Currently, the draft says that you SHOULD create streams in order (section 9.2). I'd like to change that SHOULD to a MUST.
Only if in order stream creation is a requirement, this question becomes an API design question.

Regards,
Marten



On Thu, Apr 5, 2018 at 7:14 PM Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>> wrote:
This is not a QUIC transport draft concern. This is a question of QUIC library API design. Your API may choose to have Accept return streams in order. My API may choose to have Accept return streams as they come in (and expose steam IDs). As long as the transport draft requires that streams are CREATED in order (as it does now), both API designs are valid.

It would be a matter of a very different draft to standardize QUIC APIs (like we have for POSIX) so an application can be easily ported to use a different vendor's QUIC libraries.


- Igor



-----Original Message-----
From: Marten Seemann [martenseemann@gmail.com<mailto:martenseemann@gmail.com>]
Received: Monday, 02 Apr 2018, 7:43AM
To: QUIC WG [quic@ietf.org<mailto:quic@ietf.org>]
Subject: Implicitly opened streams and exposing stream IDs

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.