IETF Logo Mail Archive

RE: draft-lubashev-quic-partial-reliability

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 19 December 2017 19:26 UTC

Return-Path: <mikkelfj@gmail.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 3538212D7E9 for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 11:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7noHVb2NIPV1 for <quic@ietfa.amsl.com>; Tue, 19 Dec 2017 11:26:00 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 F3BAA1200F1 for <quic@ietf.org>; Tue, 19 Dec 2017 11:25:59 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id w127so14743710iow.11 for <quic@ietf.org>; Tue, 19 Dec 2017 11:25:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=I/NkfeNiswywhCGXb0geU0Ux/K3FJlHLwD7MV+SxnzY=; b=R1rblXQGXS/UjBUZfZqXOTy1p0o27SEsWMRvui469ez46+Atlr59zWaFMphliUir49 dfxSJu05hYHVsuwlExx2q1Sb9pToksexTaDs75iONB5t7ZH7HXBEy+F1JS8qVTLCnk53 i2sdgh+jPEUSeKVUAAdz98eh1X6iXv4OQ8FYRqlH5zn/nmD7ol+uFziirDNeU95Tsq19 iC0yejZv7VmDkh+Vb2BjBugK4ou8MTtWf/VmquqL5Ir9gZTCvL29dLqiebcrXYH2iBzl f50qHyLGSJisJc2bilS/4lvqhWrhPXoiiVxMe4IrS2u/cd8rgX/6Y9n0noO372SyCe9c +VQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=I/NkfeNiswywhCGXb0geU0Ux/K3FJlHLwD7MV+SxnzY=; b=oWcadMsxANsV1A9JEKySbWPwxLxQ/daeAf0LlCasr60uwrnRIt0w0xURgpCaPSB+Pu YrqLBV7kZalTTdWm44s1EjJGcCZjZSAitRBQM29d2lmYlkQ4x66QUz36GosNEcsFjoxU euGTP5nrvFnx9EWBOocBDqyOJpr0UiWGcsjvsR/OP5UvFAOitxdPOPU97JstU8zF8v8w PlCjFjpVsH7FtUTYua6Mx10TTUdxf76sLk8Qm92ORMQ2IQV6K5bNhUHD1cTQevwqwdal 3KlNROQsMPTGAFLmN5FAwv2thWsDoUNacQpFo/IPE63og+z81xE/oixiZEb4o4zEq+Fo iaYQ==
X-Gm-Message-State: AKGB3mKfBvbqnqQc4OzNYVvIXFG8ETzmhNABIeLDO/YASM6xj7K9hvAB /SOnCRQ2HFxQoiFT5Y0Ft5UIqJsYS6424lY2MuQ=
X-Google-Smtp-Source: ACJfBouBYy2Q+g/D6GgwG+9OFcwJ3S4g92uNh/JUSPzX5EfYZtRSRCJQGPS/+m6RW2/WHkra7+Bh6FSsT2YUvjeRpbw=
X-Received: by 10.107.170.194 with SMTP id g63mr2938847ioj.175.1513711558338; Tue, 19 Dec 2017 11:25:58 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Dec 2017 11:25:57 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <49797640bd7444f39b51a7595ee53c72@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>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 19 Dec 2017 11:25:57 -0800
Message-ID: <CAN1APdcHHC_Ekszin63ezDQfdjU06EyHRdmc82xGV18anWS4Rg@mail.gmail.com>
Subject: RE: draft-lubashev-quic-partial-reliability
To: "Lubashev, Igor" <ilubashe@akamai.com>, Lucas Pardue <lucas.pardue@bbc.co.uk>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a1141d432ba2e650560b66f34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HhnFkJEKKNVscenjJymHQB0RqQw>
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:26:01 -0000

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