Re: QUIC - Our schedule and scope

Simon Pietro Romano <spromano@unina.it> Sun, 29 October 2017 10:33 UTC

Return-Path: <spromano@unina.it>
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 205A113FE2D for <quic@ietfa.amsl.com>; Sun, 29 Oct 2017 03:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 Nyu3NWpp5-SF for <quic@ietfa.amsl.com>; Sun, 29 Oct 2017 03:33:43 -0700 (PDT)
Received: from unina.it (fmvip.unina.it [IPv6:2001:760:3403:ffff::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419AB138FA0 for <quic@ietf.org>; Sun, 29 Oct 2017 03:33:43 -0700 (PDT)
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by leas1.unina.it with ESMTP id v9TAXdGh007868-v9TAXdGj007868 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Oct 2017 11:33:39 +0100
Received: from [192.168.1.65] (93-44-59-94.ip95.fastwebnet.it [93.44.59.94]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id v9TAXcfK023126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Oct 2017 11:33:39 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_2A31D696-2C39-416F-B070-04754BE76DED"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: QUIC - Our schedule and scope
From: Simon Pietro Romano <spromano@unina.it>
In-Reply-To: <FFBE48EA-FD6F-42C6-B1A4-80C4CD8D9864@netapp.com>
Date: Sun, 29 Oct 2017 11:33:38 +0100
Cc: Mark Nottingham <mnot@mnot.net>, Lucas Pardue <Lucas.Pardue@bbc.co.uk>, QUIC WG <quic@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Message-Id: <C0A9C95B-1F30-4167-8943-EAB373F49B82@unina.it>
References: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net> <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> <FAE9A7F7-C642-4AC5-B469-91BE7189F2F0@unina.it> <FFBE48EA-FD6F-42C6-B1A4-80C4CD8D9864@netapp.com>
To: "Eggert, Lars" <lars@netapp.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cVERDyj_rmeIKGqq3gy4-92b1WU>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 29 Oct 2017 10:33:45 -0000

Hello Lars,

last comment and I’ll shut up, promised!

> Multipath *is* in the charter, and we're fully committed to supporting it. I simply can't see how getting the WG working on the details at multipath at this time will help speed up work on the protocol fundamentals. And it seems that we'd need to continuously rework multipath while we're still changing protocol fundamentals, which would create additional busy work. 

Which is exactly what I’d call adding multipath capabilities to a protocol “by design”, rather than trying to add multipath after the protocol has been specified. I think that security should have taught us a lot, when it comes to distinguishing the "patch it” vs “think of it at design time” approach.

Simon
                     				            _\\|//_
                           				   ( O-O )
      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: spromano@unina.it <mailto:spromano@unina.it>

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/



> On 29 Oct 2017, at 09:25, Eggert, Lars <lars@netapp.com> wrote:
> 
> Hi,
> 
> On 2017-10-29, at 8:01, Simon Pietro Romano <spromano@unina.it <mailto:spromano@unina.it>> wrote:
>> The sad thing about multipath is that there have been people who have worked, more than one year ago, on implementing it in a v1-compliant way. Though, the group has never wanted to give multipath a real chance to survive and has always treated it as a “potential future extension”. This has been made so clear in the mailing list that we have stopped trying to push for it.
> 
> I don't think that's a fair summary.
> 
> First, there is no v1. We're busy specifying it at the moment, and many, many fundamental things are still changing. These are taking all the cycles the WG has at the moment, and we're still not progressing at a satisfactory pace. (Which was the message that started this thread.) I also don't think that the implementations are at a stage where they can realistically think about adding multipath - most haven't even really looked at recovery in detail.
> 
> Multipath *is* in the charter, and we're fully committed to supporting it. I simply can't see how getting the WG working on the details at multipath at this time will help speed up work on the protocol fundamentals. And it seems that we'd need to continuously rework multipath while we're still changing protocol fundamentals, which would create additional busy work. 
> 
> Lars