RE: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt

"Lubashev, Igor" <ilubashe@akamai.com> Tue, 11 February 2020 21:05 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 301B412083A for <quic@ietfa.amsl.com>; Tue, 11 Feb 2020 13:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 ENr3LO_po8Km for <quic@ietfa.amsl.com>; Tue, 11 Feb 2020 13:05:01 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 0ABF112006F for <quic@ietf.org>; Tue, 11 Feb 2020 13:05:00 -0800 (PST)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 01BKwXVg013182; Tue, 11 Feb 2020 21:04:54 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 : mime-version; s=jan2016.eng; bh=qGQ7GYfDnGV7SItBrEOQYuGr5srD3fUkKqkGre09HQc=; b=XwimyKIQDgBnnVWkzd4Ii9DjZ0gvyv2rZNirM3xRrE7XoQG7X8sFITmfKXNUv7op3DJV NlGsIN8b4g9daGue1jU2V+K5MP/ldKJESDU0CObzruDEBRnvh1Kj3GvT1Vc5aUmpw3oN 3V2nqKj/xrAMdB9ukI6ACw8q+NB/fTf5p699P4gM1wBGhgtoE/V5cvgN2J6RoZ8dDEc+ ljHi7CNMTdNxRry6ElDL2DvLp/Y3uqHh+9bz95IQ2LnQHY/jefndFvSme1Ft6PlkbiCR VUAmoR9jErUqQYyzXPZSGzR84kBRhfYBl2JaOqeckh69UI5UCljN7E7a3FRZ4tgNVWmz pQ==
Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2y1p9efbsh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Feb 2020 21:04:54 +0000
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01BKXfqJ004723; Tue, 11 Feb 2020 16:04:53 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint8.akamai.com with ESMTP id 2y1s72apkt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 11 Feb 2020 16:04:52 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 11 Feb 2020 15:04:51 -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; Tue, 11 Feb 2020 15:04:51 -0600
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Roberto Peon <fenix@fb.com>, Erik Kline <ek.ietf@gmail.com>
CC: Lars Eggert <lars@eggert.org>, HAMCHAOUI Isabelle IMT/OLN <isabelle.hamchaoui@orange.com>, IETF QUIC WG <quic@ietf.org>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Subject: RE: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt
Thread-Topic: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt
Thread-Index: AQHVzLqrJ8K1dwlaC0usEEtR2wTsCqft3wQQgChYbACAAB/50IAArJaAgAABHQD//53+UA==
Date: Tue, 11 Feb 2020 21:04:50 +0000
Message-ID: <16d7759ce1de46b59d0ff0a60d22f0b2@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <157921301012.26216.13677469865378306147.idtracker@ietfa.amsl.com> <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com> <F7EA1FAE-617D-4CCD-93E9-20C0F8F7FFD8@eggert.org> <851a81d65a9a4318914b9b18fd0b0605@ustx2ex-dag1mb5.msg.corp.akamai.com> <CAMGpriUR-JBFycZcRWcnonXis0bt-QHTq08qva6fA7EU2TiV-A@mail.gmail.com> <BBE88CC9-E833-4385-8469-A35C5AE6CACF@fb.com>
In-Reply-To: <BBE88CC9-E833-4385-8469-A35C5AE6CACF@fb.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.117.59]
Content-Type: multipart/alternative; boundary="_000_16d7759ce1de46b59d0ff0a60d22f0b2ustx2exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-11_05:, , 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-2002110136
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-11_05:2020-02-11, 2020-02-11 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 mlxlogscore=999 clxscore=1011 priorityscore=1501 mlxscore=0 impostorscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002110137
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/zj-8tTYtFP3e44thvay8scJr6KQ>
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: Tue, 11 Feb 2020 21:05:08 -0000

Thanks for not laughingā€¦ šŸ˜‰

Yes, thatā€™s how I read the question, too.  Hence I replied: ā€œI agree that the draft could benefit from the explanation of why we use QUIC v1 reserved header bits instead of some bits in a lower layer (or more bits outside of the header in the QUIC packet).ā€  And I added an issue to this effect, too (https://github.com/igorlord/draft-ferrieuxhamchaoui-lossbits/issues/37).

But, since the reasoning was, indeed, missing from the draft, I kind of summarized it after.


  *   Igor

From: Roberto Peon <fenix@fb.com>

Not laughing over hereā€¦

@Igorā€”I think the question was if we could put the reasoning into the draft!
-=R

From: QUIC <quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>> on behalf of Erik Kline <ek.ietf@gmail.com<mailto:ek.ietf@gmail.com>>
Date: Tuesday, February 11, 2020 at 12:47 PM
To: "Lubashev, Igor" <ilubashe@akamai.com<mailto:ilubashe@akamai.com>>
Cc: Lars Eggert <lars@eggert.org<mailto:lars@eggert.org>>, HAMCHAOUI Isabelle IMT/OLN <isabelle.hamchaoui@orange.com<mailto:isabelle.hamchaoui@orange.com>>, IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>, "alexandre.ferrieux@orange.com<mailto:alexandre.ferrieux@orange.com>" <alexandre.ferrieux@orange.com<mailto:alexandre.ferrieux@orange.com>>, Dmitri Tikhonov <dtikhonov@litespeedtech.com<mailto:dtikhonov@litespeedtech.com>>
Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt

On Tue, Feb 11, 2020 at 8:46 AM Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>> wrote:
> From: Lars Eggert <lars@eggert.org<mailto:lars@eggert.org>>
>
> Hi,
>
> (chair hat off)
>
> the draft points to the CONEX work and says this:
>
>    This loss signaling is similar to loss signaling in [RFC7713], except
>    the Loss Event bit is reporting the exact number of lost packets,
>    whereas the Echo Loss bit in [RFC7713] is reporting an approximate
>    number of lost bytes.
>
> What it doesn't say is why the CONEX functionality is being proposed to be
> incorporated into QUIC, rather than staying at the IP level where it arguably
> belongs?

Thanks for the feedback. I agree that the draft could benefit from the explanation of why we use QUIC v1 reserved header bits instead of some bits in a lower layer (or more bits outside of the header in the QUIC packet).

The short answer is deployability.  There is no point in writing drafts that will sit on a shelf, because no one will want to deploy them for at least a decade.  CONEX is one example, plagued by the difficulty of getting IPv6 extension headers deployed.  And good luck with similar IPv4 extensions.

Hence we borrow CONEX ideas but try to implement them in a way that is still possible, while using greasing and anti-ossification techniques.

> Thanks,
> Lars

Best,
- Igor

Folks might laugh, but I think realistically we'll be looking towards UDP trailers at some point.