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

"Lubashev, Igor" <ilubashe@akamai.com> Thu, 21 November 2019 07:23 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 C001C12094E for <quic@ietfa.amsl.com>; Wed, 20 Nov 2019 23:23:22 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 v176jEwBD1YF for <quic@ietfa.amsl.com>; Wed, 20 Nov 2019 23:23:20 -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 D9649120048 for <quic@ietf.org>; Wed, 20 Nov 2019 23:23:20 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAL7N3nn000539; Thu, 21 Nov 2019 07:23:12 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=3AtgYvPckOsox6c/vAoKGefggNWndhLveax4KRPSTHs=; b=GUb8YVvIIBWM/7RX+nLQk3jQDp88DCgK6Y7+lJC3aKQdJTS3189RLYW8wWof7PzdbOeY kJSu+952PO/No2kTIc7iFo9K3LJ5bU3R2G9hYi7AZnFjKDEUGIjXuU4Bc3l8HSKY4yYv vlqRHGi/5lLIRJgs4ukArsO6Gkm+oftGFpTeOFWYXff1/+fHBhABXtx2VXwss2hEs/lH iy3h59iL2Gaw2UNWznNASBjUxxUrqSwJYgxQ5ZUBuzx5HupKkaH3BbSqC2jstSnGl2NX UH7lTrRxKt8SKeDx/hB5bor7c5iBpUy4z9vSol8z26HazGUIPBwX7C2oQnQhvbKJVJVk Vg==
Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2wafutx7cu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 07:23:11 +0000
Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAL7Gu88024750; Thu, 21 Nov 2019 02:23:10 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint6.akamai.com with ESMTP id 2wadaxu21t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 02:23:08 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 01:23:06 -0600
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.165.123]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.165.123]) with mapi id 15.00.1473.005; Thu, 21 Nov 2019 01:23:06 -0600
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Lars Eggert <lars@eggert.org>
CC: IETF QUIC WG <quic@ietf.org>, Christian Huitema <huitema@huitema.net>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Subject: RE: CONEX? (was: Re: Q and L loss bits)
Thread-Topic: CONEX? (was: Re: Q and L loss bits)
Thread-Index: AQHVoDbg9/uTCNZtvUmvO6ZyW7zzuaeVklGA//+feYA=
Date: Thu, 21 Nov 2019 07:23:06 +0000
Message-ID: <b87ec28d39004c07a05662e200f82108@ustx2ex-dag1mb5.msg.corp.akamai.com>
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>
In-Reply-To: <A6DB3084-447B-467A-B164-310C83A6526C@trammell.ch>
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.219.86]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_08:, , 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-1911140001 definitions=main-1911210064
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_08:2019-11-20,2019-11-20 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 mlxscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911210064
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/TOQATWeTnkyU8HgSgvKGdHfONSw>
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 07:23:23 -0000

A few things about the ConEx vs QL-lossbits

1. ConEx has a mechanism that is similar to L-bit (we mention ConEx RFC7713 in the draft).  But it has no equivalent of the Q-bit signal.  It is very hard to tell upstream loss from downstream loss with ConEx.

2. ConEx reports bytes, while QL-loss reports packets.  There is a trade-off here, as bytes may be more valuable, but reporting bytes can be imprecise, if the packets marked are of different size from the packets lost.  Overall, both work well enough.

3. ConEx requires more bits than what we have in QUICv1, so it would be a significant disruption to QUICv1 header format to properly implement all ConEx bits.  The Q- and L- bits are enough for the purpose.

4. CWR is an interesting signal, and I actually have a separate CWR bit (I call it "E-bit") in https://tools.ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-02#section-5 -- the -tsvwg- version of the draft.  However, it is not very closely related to loss for networks with ECN.  On an ECN-capable network for ECN-capable flows, downstream loss would become indistinguishable from downstream congestion that marks CE.  Ultimately, it seemed that given just two bits to work with, Q-bit plus a pure loss bit seemed preferable to Q-bit plus "loss-or-CE_echo" bit.  But I am happy to discuss this!

- Igor

> On Thu, Nov 21, 2019 at 2:44 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
> 
> hi Lars,
> 
> This is kind of where I was going with the "expose CWR-like semantics for loss"
> thing; "just do conex" is a much better shorthand for that.
> 
> Thanks, cheers,
> 
> Brian
> 
> > On 21 Nov 2019, at 14:42, Lars Eggert <lars@eggert.org> wrote:
> >
> > Hi,
> >
> > I'm wondering whether specifying a CONEX mapping for QUIC would satisfy
> the needs that quic-lossbits attempts to address? We could reuse an existing
> piece of IETF work.
> >
> > See https://tools.ietf.org/html/rfc7713 for an overview and
> https://tools.ietf.org/html/rfc7786 for the TCP mapping.
> >
> > Lars
> >