Re: draft-lubashev-quic-partial-reliability

Roberto Peon <fenix@fb.com> Tue, 19 December 2017 20:56 UTC

Return-Path: <prvs=3526a54fd0=fenix@fb.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 98C9D1270A0 for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 12:56:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=bhsBcfmj; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ZxFIs/oh
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 yEVAlhQPqboV for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 12:56:36 -0800 (PST)
Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 20FF61205D3 for <quic@ietf.org>; Tue, 19 Dec 2017 12:56:36 -0800 (PST)
Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJKrHNt018471; Tue, 19 Dec 2017 12:56:23 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=nHuKFJb6PgwfaVd0P0dvWCoaJLgVZzv4CMwd6/6tewE=; b=bhsBcfmjvqeB2bre5ComasR0gudUOgtvpPZG8edj2bCKzWv4OigB+NRpxxUyYRBAqGUU B3YocMKIW1GHPcfoT4Lq5s6cTKx+VLAmjlZ0k4tuRGbk2BqBiEdcj7940dj+4Qfilbry rLoQfEhBZx9IpBPitUpwtruzzCo07atT6co=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2eya01g29g-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Dec 2017 12:56:23 -0800
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.29) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 19 Dec 2017 15:56:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nHuKFJb6PgwfaVd0P0dvWCoaJLgVZzv4CMwd6/6tewE=; b=ZxFIs/ohEIGm3S376uZ4nr7Y8tI5gIAzGacXCoEFUxdSMAELLYu9I2NJnk8UvNN7h1tet/6E88WwLmuDITCNvP+q16pjHfdfLNJ7JOc0chf1K327zeGj1GsJM8SW0OKgrsq7RDH5Hf1lplKKQLRlCzO+UVetGcO7GiWaQl+/tNY=
Received: from BN6PR15MB1876.namprd15.prod.outlook.com (10.174.239.136) by BN6PR15MB1874.namprd15.prod.outlook.com (10.174.239.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 20:56:20 +0000
Received: from BN6PR15MB1876.namprd15.prod.outlook.com ([10.174.239.136]) by BN6PR15MB1876.namprd15.prod.outlook.com ([10.174.239.136]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 20:56:20 +0000
From: Roberto Peon <fenix@fb.com>
To: Ian Swett <ianswett@google.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
CC: "Lubashev, Igor" <ilubashe@akamai.com>, Christian Huitema <huitema@huitema.net>, QUIC WG <quic@ietf.org>
Subject: Re: draft-lubashev-quic-partial-reliability
Thread-Topic: draft-lubashev-quic-partial-reliability
Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAhf3aAAAIb3wAAAJgkgP//fBiA
Date: Tue, 19 Dec 2017 20:56:20 +0000
Message-ID: <D329F6FC-BBBF-491A-930D-69D8917F364E@fb.com>
References: <c1f5a6d8d21f423a93003f7b69dae882@usma1ex-dag1mb5.msg.corp.akamai.com> <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> <DBXPR07MB35186F7E079D995ED78C95FC20F0@DBXPR07MB351.eurprd07.prod.outlook.com> <CAKcm_gPqxwbPuDo6G0=4ix7f94ahejzYAO4m0Ssn5VZv6J_bhQ@mail.gmail.com>
In-Reply-To: <CAKcm_gPqxwbPuDo6G0=4ix7f94ahejzYAO4m0Ssn5VZv6J_bhQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c090:200::7:5c29]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR15MB1874; 20:7H1uz5k3+dqJk2UGdae0y/m0j06/xCICjZNDU2L/8RaDqYWuDIsLHemnJC2nUVVsaXDblQIjgowfaZ60vhW48yfYdnhWxzXcyGr5K3X90gg6Ynq6eKKe7DcLdmeG+Su3zJnuDrLEE0CljTZLdcWKSd8xfWcqLWytAf8zOYPW7+o=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 75999f70-f891-4c5b-fa63-08d54722f4b5
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:BN6PR15MB1874;
x-ms-traffictypediagnostic: BN6PR15MB1874:
x-microsoft-antispam-prvs: <BN6PR15MB18742D738382AF512E3264C0CD0F0@BN6PR15MB1874.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(278428928389397)(166708455590820)(211936372134217)(153496737603132)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231023)(11241501184)(920507027)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(6072148)(201708071742011); SRVR:BN6PR15MB1874; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR15MB1874;
x-forefront-prvs: 052670E5A4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(346002)(396003)(24454002)(13464003)(199004)(189003)(53936002)(3660700001)(229853002)(77096006)(3280700002)(6486002)(6116002)(93886005)(2906002)(102836003)(5660300001)(36756003)(6436002)(14454004)(6506007)(236005)(6512007)(59450400001)(53546011)(54896002)(6306002)(76176011)(99286004)(478600001)(966005)(6246003)(33656002)(97736004)(82746002)(34040400001)(7736002)(81166006)(2950100002)(4326008)(86362001)(8936002)(230783001)(2900100001)(68736007)(25786009)(110136005)(81156014)(83716003)(54906003)(8676002)(105586002)(606006)(316002)(106356001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR15MB1874; H:BN6PR15MB1876.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D329F6FCBBBF491A930D69D8917F364Efbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 75999f70-f891-4c5b-fa63-08d54722f4b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 20:56:20.1257 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR15MB1874
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/qCS2OntIzRK0THxM1UruSp3yGTE>
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, 19 Dec 2017 20:56:38 -0000

It would be best to have a grouping of individually named atoms (whether streams or messages, doesn’t matter) so that we don’t jettison the ability to cache.
-=R

From: QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <ianswett@google.com>
Date: Tuesday, December 19, 2017 at 12:49 PM
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: "Lubashev, Igor" <ilubashe@akamai.com>, Christian Huitema <huitema@huitema.net>, QUIC WG <quic@ietf.org>
Subject: Re: draft-lubashev-quic-partial-reliability

For message style payloads commonly carried over UDP, like RTP, I added an issue to create a MESSAGE frame for QUIC.  Does that fit what you have in mind?
https://github.com/quicwg/base-drafts/issues/814

On Tue, Dec 19, 2017 at 3:31 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>> wrote:
> -----Original Message-----
> From: Christian Huitema [mailto:huitema@huitema.net<mailto:huitema@huitema.net>]
> Sent: den 19 december 2017 20:31
> To: Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>>; QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>
> Subject: Re: draft-lubashev-quic-partial-reliability
>
> On 12/18/2017 7:39 PM, Lubashev, Igor wrote:
>
> > The high-level idea is that the sender keeps track of messages within
> > a stream and can "expire" old messages whenever it wants.  The
> > "expiration" is a signal to the transport to not retransmit expired
> > data (and a signal to the other endpoint that this data will not be
> > retransmitted).  All details are in the draft.
>
> I read your draft, and it does indeed provide "partial reliability." My problem
> is that for RTP style applications, you don't want just partial reliability. You
> also want application frame delimitation, such as delivering isolated VOIP
> frames, doing  loss compensation, or implementing application level FEC for
> large video frames. The streams in QUIC don't provide that. They implement
> a "byte stream" abstraction, not a "packet stream". So I really wonder
> whether FTP style applications are better served by adding partial reliability
> to the current concept of streams, or whether we should just add a different
> service, maybe creating "RTP_STREAM" frames.

Thanks Christian, I now understand what I did not understand with the partial-reliability draft. The reason is that I look at this from an RTP point of view. To make QUIC {partial,un}reliable streams useful for real time media then I agree that one need something like RTP_STREAM. With that said I am not sure that RTP is the best common denominator around, perhaps MEDIA_STREAM is a better alternative?, where one use the abstraction media frames (video frames, audio frames...) instead ?, that would allow support for other not RTP type packetization like for instance MPEG-TS .

>
> -- Christian Huitema
>
>