IETF Logo Mail Archive

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

Lars Eggert <lars@eggert.org> Tue, 11 February 2020 08:35 UTC

Return-Path: <lars@eggert.org>
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 E44331201E3 for <quic@ietfa.amsl.com>; Tue, 11 Feb 2020 00:35:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 KG3zbt62aKyU for <quic@ietfa.amsl.com>; Tue, 11 Feb 2020 00:35:21 -0800 (PST)
Received: from vs25.mail.saunalahti.fi (vs25.mail.saunalahti.fi [62.142.117.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0873D120091 for <quic@ietf.org>; Tue, 11 Feb 2020 00:35:21 -0800 (PST)
Received: from vs25.mail.saunalahti.fi (localhost [127.0.0.1]) by vs25.mail.saunalahti.fi (Postfix) with ESMTP id 3BF3520F4D; Tue, 11 Feb 2020 10:35:18 +0200 (EET)
Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs25.mail.saunalahti.fi (Postfix) with ESMTP id 30B6D20F1C; Tue, 11 Feb 2020 10:35:18 +0200 (EET)
Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw01.mail.saunalahti.fi (Postfix) with ESMTPSA id 105AD40005; Tue, 11 Feb 2020 10:35:12 +0200 (EET)
Received: from dhcp-100-247.eduroam.aalto.fi (dhcp-100-247.eduroam.aalto.fi [130.233.100.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 481C36163A4; Tue, 11 Feb 2020 10:35:05 +0200 (EET)
From: Lars Eggert <lars@eggert.org>
Message-Id: <F7EA1FAE-617D-4CCD-93E9-20C0F8F7FFD8@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_CFD1F578-C992-4D65-838C-49BAEFAE69D7"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt
Date: Tue, 11 Feb 2020 10:35:04 +0200
In-Reply-To: <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com>
Cc: IETF QUIC WG <quic@ietf.org>, HAMCHAOUI Isabelle IMT/OLN <isabelle.hamchaoui@orange.com>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>
References: <157921301012.26216.13677469865378306147.idtracker@ietfa.amsl.com> <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com>
X-MailScanner-ID: 481C36163A4.A3CDA
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/srruAWCMEkFhurquaKjDQpwDk-A>
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 08:35:23 -0000

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,
Lars

v2.23.0 | Report a Bug | By Email