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.
- Q and L loss bits: which is which? Dmitri Tikhonov
- Re: Q and L loss bits: which is which? alexandre.ferrieux
- Re: Q and L loss bits: which is which? Dmitri Tikhonov
- Re: Q and L loss bits: which is which? alexandre.ferrieux
- Re: Q and L loss bits: which is which? Dmitri Tikhonov
- Re: Q and L loss bits: which is which? Christian Huitema
- RE: Q and L loss bits: which is which? Lubashev, Igor
- Re: Q and L loss bits: which is which? Brian Trammell (IETF)
- Re: Q and L loss bits: which is which? alexandre.ferrieux
- Re: Q and L loss bits: which is which? Christian Huitema
- RE: Q and L loss bits: which is which? Lubashev, Igor
- Re: Q and L loss bits: which is which? Dmitri Tikhonov
- RE: Q and L loss bits: which is which? Lubashev, Igor
- CONEX? (was: Re: Q and L loss bits) Lars Eggert
- Re: CONEX? (was: Re: Q and L loss bits) Brian Trammell (IETF)
- RE: CONEX? (was: Re: Q and L loss bits) Lubashev, Igor
- Re: CONEX? (was: Re: Q and L loss bits) Brian Trammell (IETF)
- Re: CONEX? (was: Re: Q and L loss bits) alexandre.ferrieux