IETF Logo Mail Archive

Re: draft-lubashev-quic-partial-reliability

Christian Huitema <huitema@huitema.net> Tue, 19 December 2017 19:31 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 D151D12D830 for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 11:31:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 52c3o27q9FY8 for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 11:31:12 -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 16A6112D82D for <quic@ietf.org>; Tue, 19 Dec 2017 11:31:12 -0800 (PST)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eRNbY-0007Eu-8x for quic@ietf.org; Tue, 19 Dec 2017 20:31:09 +0100
Received: from [10.5.2.17] (helo=xmail07.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 1eRNbW-00052F-7B for quic@ietf.org; Tue, 19 Dec 2017 14:31:07 -0500
Received: (qmail 21831 invoked from network); 19 Dec 2017 19:31:04 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 19 Dec 2017 19:31:04 -0000
To: "Lubashev, Igor" <ilubashe@akamai.com>, QUIC WG <quic@ietf.org>
References: <c1f5a6d8d21f423a93003f7b69dae882@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net>
Date: Tue, 19 Dec 2017 11:31:01 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <c1f5a6d8d21f423a93003f7b69dae882@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
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.59)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5mejodwnrW+nNt0lzyyKp64Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fu7Ve+IJooKvShhDVWyxDygB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CgKaGzfcJ00EPsiVhfSKl3mx+PIL1ombXfQrNjRfO/VOx6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGcyNBJprCgmabT8JgPqpM5mTFkJCfQx95lvhVaK1R9QMX /Lgz0mucCFazxyRnx4XXBGWb7fPzS53ef0WN2OlcClz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiB8jSoYz6mw6iMTDK1bQzS5x3h1vgDbEdmhrg3iVBpdRZRb8Vdsy5LZaUHXrX9gYVqGpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_st36nxrqS-Xr1saDIglDvXydtQ>
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 19:31:14 -0000

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.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email