RE: draft-lubashev-quic-partial-reliability

"Lubashev, Igor" <ilubashe@akamai.com> Tue, 19 December 2017 21:45 UTC

Return-Path: <ilubashe@akamai.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 F309212D856 for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 13:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 Y7uo4hH4W9hp for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 13:45:52 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 480FA1200FC for <quic@ietf.org>; Tue, 19 Dec 2017 13:45:52 -0800 (PST)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJLgL1j030492; Tue, 19 Dec 2017 21:45:45 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=4tkWRTVo0uxCut8uFDT3Ci79foKhZqwd69MU7D0BN/o=; b=BxIe13nk86aWtJrTpMaICD8S0EC/M9YiLLl/tt4BEMW10dh/05tu305wCzCp4g9JCNsK Q7AfOGPJryWm31KDEUflwvNKySMZ3jByegx18S4HHAgfOU1pMwV6PdLnjM9vIcTSviyG w561crG72bDkfZXHNtJ2qXoCXtwn4l0uHX4y77TACzTFp7vWBE4jLZTAnDZNgQrkoxTM mjtKIet07IxiJlLP9jbyZIpm0hb6l7RbLsibKfb90b0virPfo01GoMaKi8X/kyY3XgZr YNYZmZZHUb3dEu+i4F4fj4kJXd2o/dbhzNn1POq5uaX6WRe0SPJdoHq3gfAJlJICg3s5 OQ==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2evuw6b9m8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 21:45:45 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBJLetuc018467; Tue, 19 Dec 2017 16:45:43 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2evyqdwvnq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 16:45:43 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Dec 2017 16:45:42 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Tue, 19 Dec 2017 16:45:42 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: 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: AdN4eekQTxka84DaTqiLnO0Um5bpqQAr+ayAAAX9L9A=
Date: Tue, 19 Dec 2017 21:45:42 +0000
Message-ID: <dd0a88864e334333a3c265a3847704f9@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <c1f5a6d8d21f423a93003f7b69dae882@usma1ex-dag1mb5.msg.corp.akamai.com> <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net>
In-Reply-To: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.35.55]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190307
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190307
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/lS5JfPiuN48riv_mwTNUlNA0Mok>
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:45:54 -0000

> My problem is that for RTP style applications, you don't want just partial reliability. You also want application frame delimitation [...]

This is what this draft is trying to give you.

>From Section 5 "Sender Interface and Behavior"

"A typical sender would call an API function providing this functionality
   whenever any data previously enqueued for transmission expires, per
   application semantics.  The sender would keep track of the message
   boundaries of such data."

Hence, since the sender knows message boundaries (you call them "application frame delimitation") within the data stream, the sender can choose the offset to expire data.  The one thing this draft will NOT let you do is expire selective ranges of data within a data stream -- it only supports expiring "all data up to offset X".

- Igor

-----Original Message-----
From: Christian Huitema [mailto:huitema@huitema.net] 
Sent: Tuesday, December 19, 2017 2:31 PM
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.

-- Christian Huitema