From nobody Fri Oct 21 08:55:22 2022 Return-Path: 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 A357DC152568 for ; Fri, 21 Oct 2022 08:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y95bvrNs-35e for ; Fri, 21 Oct 2022 08:55:20 -0700 (PDT) Received: from mail1.bemta37.messagelabs.com (mail1.bemta37.messagelabs.com [85.158.142.113]) (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 9DC7CC1524DD for ; Fri, 21 Oct 2022 08:55:19 -0700 (PDT) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRWlGSWpSXmKPExsXSsnPBFt3HB4K SDW79tLRY/eI2i8WBP+uZLJ6tWslmcaPhB4tFzwJuB1aPJUt+Mnk87O5k9Hh17DtLAHMUa2Ze Un5FAmvGvOlhBTdEKp5uKW9gfCXQxcjFISSwk1Hi4dt2ZghnOaPE+QcP2CGc3YwSE7rXAmU4O XgF7CVuLdkJZrMIqEoc7t3LBhEXlDg58wkLiC0qEClx4+1xJhBbWMBbYsGzj+wgNrOAuMStJ/ PB4iICURKvp31kA1nALDCFUeLj481gRUICFRL3V+8HW8AmoCnx6ecusAWcAg4SXe9fs0IMMpP o2trFCGHLSzRvnc08gVFgFpI7ZiHZNwtJyywkLQsYWVYxmhenFpWlFukaWuolFWWmZ5TkJmbm 6CVW6SbqpZbq5uUXlWToGuollhfrpRYX6xVX5ibnpOjlpZZsYgRGREpxavQOxrnL/ugdYpTkY FIS5Y2YGJQsxJeUn1KZkVicEV9UmpNafIhRhoNDSYJ35x6gnGBRanpqRVpmDjA6YdISHDxKIr yps4DSvMUFibnFmekQqVOMuhzN/38fYBZiycvPS5US5/0EMkMApCijNA9uBCxRXGKUlRLmZWR gYBDiKUgtys0sQZV/xSjOwagkzNu7G2gKT2ZeCdymV0BHMAEdcWkF2BEliQgpqQYmxoOrDaZl CCuyxweed+IWMt7OtUz1xMw1LRlO3dKPy4QlHgVLqHaYrCtrUT/HuaFYV01DaZ85w/pnwTEmd 5ceiHTU0VcPP9Uds8+k55f3+XlS/PUlLYqaQk8XnbgkqqDyRcXRtXJC/FRLb/8XRmyql0UWft fq+m38O5N5t5pl09ni91//BjrEiPyfvYNHNlb7EXOy0DzjWQ+/54ndapu+p/Nb/SqOquwFctt yFLk8rJKPbUncybH3yGaOgBxlrqyD/l7V1zQnHHyhZfrBUn7y3t9/teuatpR+e+NwobzIhrss 2fLLBTdh72bel6dOsi2cMkPJ3XOlmXJmf+mv45LC/VvfXqr85TGL5cTC+UosxRmJhlrMRcWJA HmkJP+PAwAA X-Env-Sender: samuelh@rd.bbc.co.uk X-Msg-Ref: server-7.tower-722.messagelabs.com!1666367715!9713!1 X-Originating-IP: [132.185.160.180] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.100.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24419 invoked from network); 21 Oct 2022 15:55:15 -0000 Received: from mailout1.cwwtf.bbc.co.uk (HELO mailout1.cwwtf.bbc.co.uk) (132.185.160.180) by server-7.tower-722.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 21 Oct 2022 15:55:15 -0000 Received: from gateb.lh.bbc.co.uk (gateb.kw.bbc.co.uk [132.185.132.11]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id 29LFtF4W012521; Fri, 21 Oct 2022 16:55:15 +0100 (BST) Received: from mailhub1.rd.bbc.co.uk ([172.29.120.129]) by gateb.lh.bbc.co.uk (8.15.1+Sun/8.13.6) with ESMTP id 29LFtF5e020651; Fri, 21 Oct 2022 16:55:15 +0100 (BST) Received: from [172.29.197.247] (port=46270) by mailhub1.rd.bbc.co.uk with esmtp (Exim 4.92) (envelope-from ) id 1oluMc-0007jw-UZ; Fri, 21 Oct 2022 16:55:14 +0100 Message-ID: <0d306235-b54f-40a2-01f5-7e4d93368629@rd.bbc.co.uk> Date: Fri, 21 Oct 2022 16:55:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: Fwd: New Version Notification for draft-michel-quic-fec-00.txt Content-Language: en-US To: =?UTF-8?Q?Fran=c3=a7ois_Michel?= , quic@ietf.org Cc: Olivier Bonaventure , Marie-Jose Montpetit , louis.navarre@uclouvain.be References: <166635428256.33398.3422317514834517586@ietfa.amsl.com> <6339ddf0-aad1-2579-4a75-2c1d0fa5f94b@uclouvain.be> From: Samuel Hurst In-Reply-To: <6339ddf0-aad1-2579-4a75-2c1d0fa5f94b@uclouvain.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2022 15:55:20 -0000 Hello Francois, On 21/10/2022 13:49, François Michel wrote: > Here is a draft discussing the addition of Forward Erasure Correction to > QUIC. > > We wrote this draft to discuss FEC in QUIC and experiment with people. > It is inspired by our previous work at the nwcrg. Thanks very much for publishing and sharing your draft with the group. The use of FEC with QUIC is of interest to me and I have previously looked at the applicability of AL-FEC to our Multicast QUIC draft [1]. > We also have interesting real-network results that we would be happy to show to > motivate the interest for this extension. I for one would be very interested in your results. > The design is at an early stage and is intended to evolve. Do not > hesitate to provide us with comments on the document or the extension in > general. I've given your draft a quick read through this afternoon and I have a few bits of feedback: * I'm not entirely convinced that being able to protect only part of a QUIC packet is that useful, as I worry that while you might be able to repair the protected contents, how do you know what else was in a packet? You're still going to have to get a retransmission of the whole packet, which increases network load. I personally think it would be more helpful to be able to prevent the emission of a packet if the whole thing can be recovered using FEC. * In section 5.2, you correctly identify that QUIC packet numbers may not necessarily increase contiguously, but have you considered perhaps writing your extension in such a way that your profile of QUIC transport requires that senders increase packet numbers contiguously so that you don't need yet another packet identifier? * Also in section 5.2, you talk about carrying the symbol ID in a frame or a dedicated header field, then specify that the latter is incompatible with QUICv1 and that it is not discussed further in this document. This then tripped me up when I read the following two alternatives, mistakenly believing that the second one was incompatible. I believe that removing the reference to the header field option if you're not otherwise going to describe it would aid comprehension. * Have you considered referencing and using the IETF FECFRAME from RFC6363? It might help when it comes to adopting existing FEC mechanisms into QUIC, such as using the RMT FEC Encoding IDs as the basis for your identifier in the decoder_fec_scheme transport parameter. The draft is a great start, and I look forward to seeing where it goes next. Best regards, -Sam -- [1]: https://www.ietf.org/archive/id/draft-pardue-quic-http-mcast-11.html