IETF Logo Mail Archive

RE: draft-lubashev-quic-partial-reliability

"Lubashev, Igor" <ilubashe@akamai.com> Wed, 20 December 2017 03:03 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 B2FD812D948 for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 19:03:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 MvQDJUTVxTJd for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 19:03:28 -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 34F12124D85 for <quic@ietf.org>; Tue, 19 Dec 2017 19:03:27 -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 vBK32o1c027813; Wed, 20 Dec 2017 03:03:22 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 : mime-version; s=jan2016.eng; bh=nB5h7Nt6PJYGpAPlmRZ98VzAi6WynwnhAXSAdfiAeJ8=; b=CuOpohpZthuwHJBKknmwffTQaZ6MxY5H/MlyUuCZsZ7AepKwZKCNf6E1sv17bTdDpztL tRs5qwgvh11epvLnwMLEvG8lV6DwCgf+lPxJ2d1VX8/Za7ebkNTzmIVeBOdx26Y0Qkbe Ssva3TstRilApUP9rGFf2ji1KQ95nebD9B9vLClwULySgKB5HkKKCFle7Byp6ntkyzO0 cypGKNLBBJQi9Zn2AgxkC+jKuBpJlWysJMaDeJbo5WeNr+uFN11OPdHHrzgNyIlcaSSt WbK58VGuvJNiamRww2XWF5OCeoUr9uC/8Z4isrzEytrpSCQYenc6ldcWvHJXH8TFhjE5 TQ==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2evuw6c1g2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Dec 2017 03:03:22 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBK30lis030661; Tue, 19 Dec 2017 22:03:21 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2evypxxt8r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 22:03:21 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Dec 2017 22:03:20 -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 22:03:20 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Lucas Pardue <lucas.pardue@bbc.co.uk>, "quic@ietf.org" <quic@ietf.org>
Subject: RE: draft-lubashev-quic-partial-reliability
Thread-Topic: draft-lubashev-quic-partial-reliability
Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAMOJHZAAgTzPAAAesSEAARBPyAAAhDLtD//+JmgP//26VA
Date: Wed, 20 Dec 2017 03:03:19 +0000
Message-ID: <5a3b3547c4f24b55aaf949c967e44e1c@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <c1f5a6d8d21f423a93003f7b69dae882@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> <CAN1APddU53Jzfy998NtOqVZC8ZdXYGEZf042VKw7yMGCixq-bg@mail.gmail.com> <49797640bd7444f39b51a7595ee53c72@usma1ex-dag1mb5.msg.corp.akamai.com> <CAN1APdcHHC_Ekszin63ezDQfdjU06EyHRdmc82xGV18anWS4Rg@mail.gmail.com>
In-Reply-To: <CAN1APdcHHC_Ekszin63ezDQfdjU06EyHRdmc82xGV18anWS4Rg@mail.gmail.com>
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: multipart/alternative; boundary="_000_5a3b3547c4f24b55aaf949c967e44e1cusma1exdag1mb5msgcorpak_"
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-1712200041
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-1712200042
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/W0tVa3qZI3_YH3JQvc43FPVQcco>
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: Wed, 20 Dec 2017 03:03:30 -0000

  *   If the connection has low loss-rate, it might start retransmitting a lot of data that the application already knows is no longer relevant […]

Are you worried about a case of message expiration being shorter than an rtt, and hence the application would expire messages at a rate faster than the ACKs can be received?   That would not cause any extra retransmissions, but it would cause unnecessary MIN_STREAM_DATA frames, indeed.




  *   QUIC bytes “exempt” from Flow Control

I think, yes, QUIC packets have many bytes exempt from flow control (STREAM frame headers and all non-STREAM frames).  One-stream-per-message is going to have the same overhead in “exempt bytes” as emitting one MIN_STREAM_DATA per message.


From: Mikkel Fahnøe Jørgensen [mailto:mikkelfj@gmail.com]
Sent: Tuesday, December 19, 2017 2:26 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Lucas Pardue <lucas.pardue@bbc.co.uk>; quic@ietf.org
Subject: RE: draft-lubashev-quic-partial-reliability

Yes, this is an application concern, since only the application can know what “old” means.  Also, since MIN_FRAME_DATA  frame is emitted ONLY if some expired stream data is lost (not ACKed), you would not expect to see many such frames on the wire, even if messages keep expiring all the time.

I could be that the approach is not aggressive enough. If the connection has low loss-rate, it might start retransmitting a lot of data that the application already knows is no longer relevant, before the NACK (ACK gap) arrives cost excessive bandwidth.

In a recent TCP vs QUIC paper posted here, that was an unanswered question about why QUIC took double the bandwidth of TCP when both were competing using CUBIC. This might be related to QUIC being able to make faster retransmission decisions on more packets which do not count against its flow control window (right?).

v2.23.0 | Report a Bug | By Email