IETF Logo Mail Archive

RE: Unreliable Stream Support for QUIC

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Tue, 05 September 2017 17:20 UTC

Return-Path: <Lucas.Pardue@bbc.co.uk>
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 46BA6132DD6 for <quic@ietfa.amsl.com>; Tue, 5 Sep 2017 10:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 1ziBdVQ-j1jC for <quic@ietfa.amsl.com>; Tue, 5 Sep 2017 10:20:35 -0700 (PDT)
Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9270D132D62 for <quic@ietf.org>; Tue, 5 Sep 2017 10:20:35 -0700 (PDT)
Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v85HKXC7007337; Tue, 5 Sep 2017 18:20:34 +0100 (BST)
Received: from BGB01XI1015.national.core.bbc.co.uk (10.161.14.78) by BGB01XI1011.national.core.bbc.co.uk (10.161.14.15) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 5 Sep 2017 18:20:33 +0100
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1015.national.core.bbc.co.uk ([10.161.14.78]) with mapi id 14.03.0319.002; Tue, 5 Sep 2017 18:20:32 +0100
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: "Philipp S. Tiesel" <phils@in-panik.de>, QUIC WG <quic@ietf.org>
Subject: RE: Unreliable Stream Support for QUIC
Thread-Topic: Unreliable Stream Support for QUIC
Thread-Index: AQHTJmRPDJY4uXGd60ScIiysX8LipqKmiHIg
Date: Tue, 05 Sep 2017 17:20:32 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A37766AB0@bgb01xud1012>
References: <A9B224F6-E917-4A7F-ABF7-29FC2C60C5A6@in-panik.de>
In-Reply-To: <A9B224F6-E917-4A7F-ABF7-29FC2C60C5A6@in-panik.de>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.212]
X-TM-AS-Product-Ver: SMEX-11.0.0.4255-8.100.1062-23306.000
X-TM-AS-Result: No--11.250300-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EXCLAIMER-MD-CONFIG: c91d45b2-6e10-4209-9543-d9970fac71b7
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/akIg69FowGsqMoHCeHUCkm_0Cd0>
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, 05 Sep 2017 17:20:37 -0000

Hi Philipp,

Thanks for publishing these. I've only had a chance to skim read so I only have a basic question right now.

For the HTTP/QUIC mapping, have you considered server push? The document doesn't mention anything but I wonder if you have some ideas. I'm thinking that the push promise includes your request header to indicate to the client that the pushed body will be unreliable. An alternative would be to have all pushed streams inherit the reliability of the parent stream. 

Kind regards
Lucas
________________________________________
From: QUIC [quic-bounces@ietf.org] on behalf of Philipp S. Tiesel [phils@in-panik.de]
Sent: 05 September 2017 17:29
To: QUIC WG
Subject: Unreliable Stream Support for QUIC

Hi,

as promised, we just submitted a draft on unreliable streams for QUIC,
including support for partial reliability:
   https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-streams/

TL;DR:

 - In principal, supporting unreliable streams in QUIC
   does not require changes to the datft-05 wire-protocol.

 - To get a nice interface between QUIC transport and the
   application, we need one bit in the stream frame header
   to indicate whether a stream is supposed to be reliable.


To give an application example, we did also draft how HTTP/2 over QUIC
can be extended to support partial reliability based on the draft above:
   https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-http/

We have no finished implementation yet, but are working on one.

AVE!
  Philipp S. Tiesel / phils…

v2.23.0 | Report a Bug | By Email