Re: draft-lubashev-quic-partial-reliability

Colin Perkins <csp@csperkins.org> Tue, 19 December 2017 21:48 UTC

Return-Path: <csp@csperkins.org>
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 3DEE212D85F for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 13:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 DHaV1QzN9kpz for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 13:48:11 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 BDFDF1200FC for <quic@ietf.org>; Tue, 19 Dec 2017 13:48:11 -0800 (PST)
Received: from [81.187.2.149] (port=44197 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <csp@csperkins.org>) id 1eRPk5-0001G1-2k; Tue, 19 Dec 2017 21:48:06 +0000
From: Colin Perkins <csp@csperkins.org>
Message-Id: <C3E9D449-356D-4E87-B774-E697DB7267B5@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8BE2E5E2-8A46-4E44-AF5E-4C636E035AE7"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: draft-lubashev-quic-partial-reliability
Date: Tue, 19 Dec 2017 21:47:58 +0000
In-Reply-To: <DBXPR07MB35186F7E079D995ED78C95FC20F0@DBXPR07MB351.eurprd07.prod.outlook.com>
Cc: Christian Huitema <huitema@huitema.net>, "Lubashev, Igor" <ilubashe@akamai.com>, QUIC WG <quic@ietf.org>
To: 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>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/FtdRh6RWHDW-D1p2a43oRb-G3Qg>
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:48:14 -0000

> On 19 Dec 2017, at 20:31, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
>> -----Original Message-----
>> From: Christian Huitema [mailto:huitema@huitema.net]
>> Sent: den 19 december 2017 20:31
>> To: Lubashev, Igor <ilubashe@akamai.com>; QUIC WG <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 .


RTP has many other features that will confuse if we’re not careful… Framed messages, rather than unframed byte streams, might be the key abstraction? Once we have that, partial reliability, dependancies, deadlines, and unordered delivery become natural to add.

-- 
Colin Perkins
https://csperkins.org/