Re: CONEX? (was: Re: Q and L loss bits)

<alexandre.ferrieux@orange.com> Thu, 21 November 2019 12:16 UTC

Return-Path: <alexandre.ferrieux@orange.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 0FC3F1208A7 for <quic@ietfa.amsl.com>; Thu, 21 Nov 2019 04:16:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ozAB8hkYZRUh for <quic@ietfa.amsl.com>; Thu, 21 Nov 2019 04:16:29 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A44B12087B for <quic@ietf.org>; Thu, 21 Nov 2019 04:16:29 -0800 (PST)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 47Jdp41WjwzFq0w; Thu, 21 Nov 2019 13:16:28 +0100 (CET)
Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.92]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 47Jdp373Szz3wbD; Thu, 21 Nov 2019 13:16:27 +0100 (CET)
Received: from lat6466.rd.francetelecom.fr (10.114.50.247) by OPEXCNORMAC.corporate.adroot.infra.ftgroup (10.114.50.92) with Microsoft SMTP Server (TLS) id 14.3.468.0; Thu, 21 Nov 2019 13:16:27 +0100
Message-ID: <32472_1574338588_5DD6801C_32472_5_1_1574338604.25904.2.camel@orange.com>
Subject: Re: CONEX? (was: Re: Q and L loss bits)
From: alexandre.ferrieux@orange.com
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, "Lubashev, Igor" <ilubashe@akamai.com>
CC: Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>, Christian Huitema <huitema@huitema.net>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
In-Reply-To: <55785142-03C8-48E0-B497-419AED1D1F15@trammell.ch>
References: <20191119143218.GB2789@ubuntu-dmitri> <24388_1574174932_5DD400D4_24388_372_7_1574174948.30247.49.camel@orange.com> <20191119150829.GD2789@ubuntu-dmitri> <20191119192622.GE2789@ubuntu-dmitri> <a21bc373-1fda-836e-7efc-599832ae575d@huitema.net> <20191120014850.GC16017@ubuntu-dmitri> <cd2e9389a61d49eabad2b0fac2f4db96@ustx2ex-dag1mb5.msg.corp.akamai.com> <A5687771-2F40-419F-A8A2-00FFF919B3FA@eggert.org> <A6DB3084-447B-467A-B164-310C83A6526C@trammell.ch> <b87ec28d39004c07a05662e200f82108@ustx2ex-dag1mb5.msg.corp.akamai.com> <55785142-03C8-48E0-B497-419AED1D1F15@trammell.ch>
Content-Type: text/plain; charset="ISO-8859-1"
Date: Thu, 21 Nov 2019 13:16:44 +0100
MIME-Version: 1.0
X-Mailer: Evolution 3.22.6-1+deb9u2
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.114.50.247]
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HU8-xhMNdn6keZCEfeKKgM_ibsA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 21 Nov 2019 12:16:31 -0000

On Thu, 2019-11-21 at 18:07 +0800, Brian Trammell (IETF) wrote:
> What I'd like to look at is a one-bit encoding for L that exposes the
> same signals ConEx did. It turns out this might be about the same
> thing as L as currently defined when L doesn't count losses
> determined to be spurious.

It might very well :)

Any other signal than loss is out of scope in many real-life scenarii:
a router that loses packets well below capacity due to internal
implementation limitations (read "bugs") will certainly *not* CE-mark
any packet; it will just drop in sheer panic. The "pre-ECN world" is
not dead.

Regarding spurious losses: you're right, it would be better if we had a
sure-fire method to eliminate them from L. Attempts to do that were
recently mentioned here. A reasonable, conservative one was proposed by
Igor yesterday:

"Ok, I think there is a better middle ground.  If the counter is > 0,
sure, decrement it (since the loss has not yet been reported).  But if
the counter is already 0, do not let it go negative, because then you
would not be able to report an actual future loss event (and an actual
future congestion controller response)."

To judge the importance of this issue, it would be good to have an idea
of the frequency of such (DSACK-like) spurious events under varied
assumptions.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.