IETF Logo Mail Archive

Re: draft-lubashev-quic-partial-reliability

Christian Huitema <huitema@huitema.net> Tue, 19 December 2017 21:58 UTC

Return-Path: <huitema@huitema.net>
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 B0B2D124BAC for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 13:58:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 5k1w1cUZfhIy for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 13:58:53 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 EBA7A1200FC for <quic@ietf.org>; Tue, 19 Dec 2017 13:58:52 -0800 (PST)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx19.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eRPuT-00063Z-7F for quic@ietf.org; Tue, 19 Dec 2017 22:58:50 +0100
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eRPuO-0005V5-CQ for quic@ietf.org; Tue, 19 Dec 2017 16:58:48 -0500
Received: (qmail 13729 invoked from network); 19 Dec 2017 21:58:43 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 19 Dec 2017 21:58:43 -0000
To: Ian Swett <ianswett@google.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.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>
Cc: "Lubashev, Igor" <ilubashe@akamai.com>, QUIC WG <quic@ietf.org>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <496d69f0-8c88-134a-d80d-a4fcb07249f9@huitema.net>
Date: Tue, 19 Dec 2017 13:58:52 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAKcm_gPqxwbPuDo6G0=4ix7f94ahejzYAO4m0Ssn5VZv6J_bhQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: draft-lubashev-quic-partial-reliability
X-Originating-IP: 168.144.250.223
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.11)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5hQfmGMyLVXJokjUP4fI3lMXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsKNPILOWNIp50KNu32/z0EB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYfVCZ1my7qTGj+pYSPpnV3tZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xe5FFYx70dwpnXuYL0mrvA8FWxgXlWmTYKYIcQI2OJ epHQ4lRr5p6yleZoFrtpXFkHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFCFnwGKkv+DIQGXVP+Qhqh8ibYT4C2qF2lnc18bVJn66g m3XMthnh0ALITSE6NJwtyvmR2nbAco/KthuxWjUkZDwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTcmOtKpb1oAulsHm1CrhdOljI1dRH6f16eQCtvwPkeoyl2uO1aNahU3xgdP6yeyunl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/wHohMXpgMkfgPKqEj5V8cONgmuU>
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 21:58:55 -0000

On 12/19/2017 12:48 PM, Ian Swett wrote:

> 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

Not quite. RTP has the concept of streams, with applications negotiating
what stream carries what kind of media payload. They also have a concept
of "sequence of messages", so they can determine which packets in a
stream are missing and apply whatever corrective process is appropriate.
And then there time stamps, and source identifiers...

Applications could indeed use a MESSAGE frame and put their own RTP
style headers inside it. But that feels like punting to the app. I am
kind of hoping that we can do a bit better.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email