Re: QUIC - Our schedule and scope
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 30 October 2017 01:53 UTC
Return-Path: <spencerdawkins.ietf@gmail.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 2EE581394EB for <quic@ietfa.amsl.com>; Sun, 29 Oct 2017 18:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 UynaB2ppicud for <quic@ietfa.amsl.com>; Sun, 29 Oct 2017 18:53:52 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB93138B5E for <quic@ietf.org>; Sun, 29 Oct 2017 18:53:52 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id y75so10245742ywg.0 for <quic@ietf.org>; Sun, 29 Oct 2017 18:53:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UBxozt4KOm9ASemvkkzgutO37nn/Wg8KIpMZjWFoMx8=; b=CojVeIafuUo1lKyGG2WLhQDEE4s2uZs0dRiHyEfoD3U2ZslLUU7aq1iuGrnXeOuWdM MazP2AArLYl5MNTy/+Lxlmm///wLnV1X2IFC9m7eO9MG0cl4I7DOU9vN0dR9zZNIBn2+ 7RH+HVuQDdxvsJ7deVPT5/hMq4QFD049S+z7ENx4/B7LO5V4bY9+e+AQIg+eIEPwMu7W 7c4qyxEc+LmZggExLO05eTT0n5ppHOW3L6mr4DltwnI8d6Hw18Cx0zK9ArC/xq5liK1+ VwkQTJfonew9FK+lVXHFai15EdUti8c1OkHaNWWf7T/2dw+nXGjxeDY1ZmHpF9vRhj4/ jHHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UBxozt4KOm9ASemvkkzgutO37nn/Wg8KIpMZjWFoMx8=; b=uZrHjJlFIw9kw6AOQs9jVbDPvTuIH8IHSn12LmAF9z8qvuSq6rSAPiih481RjFgkwB Hf855Zmpb4TPsYpgezCu8kdWFzIPCL0/UH8Jxr84aBuIpqP6ZOQMkCrYmn11i47cCssg IqTg8w0ZX95T4XH6UXIXxN2w9hWy1QgdRGls/XzIo1LDfEyksPRvbexVP+F14kDBo6OI umfMAb6j7+ixvDPAJ87aFLN9kZnguGQjEckWYTB/lrGg5fhQpNWAn0ItRXXaeqfjfnjH CwW/5csTe+z7Y9cAbe+YGlP9M+bdf3FiLnG6S8maKPz+TaQsiw35WNq6770bEwnfxoQ5 NOxw==
X-Gm-Message-State: AMCzsaXZqDjU3Alwu4ULngG2qXBEBopow39pQDVl525pTVhh5PutwMhQ t0U+o2r49Rjd6nKIM8dCek2VKkijnOrVxDvEB3A=
X-Google-Smtp-Source: ABhQp+TxuHDA0CWy96nyrkO61y440BQ9E3sdrWvoDPYTmUJ4ak5hoxqs0useAJ02VXEujXJylEy+52Vw4bsAFeLSl68=
X-Received: by 10.37.162.41 with SMTP id b38mr4793416ybi.195.1509328431251; Sun, 29 Oct 2017 18:53:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.162.204 with HTTP; Sun, 29 Oct 2017 18:53:50 -0700 (PDT)
In-Reply-To: <FFBE48EA-FD6F-42C6-B1A4-80C4CD8D9864@netapp.com>
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>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Sun, 29 Oct 2017 20:53:50 -0500
Message-ID: <CAKKJt-e1K1LD=P217oGZ2XDmWFaLp3tmwXmYOxh+Mud+zdM3bA@mail.gmail.com>
Subject: Re: QUIC - Our schedule and scope
To: "Eggert, Lars" <lars@netapp.com>
Cc: Simon Pietro Romano <spromano@unina.it>, Mark Nottingham <mnot@mnot.net>, Lucas Pardue <Lucas.Pardue@bbc.co.uk>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c197f86fe8700055cb9e8b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mtlwhSME1ePe46ZhJcn4ZmFz0Jg>
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: Mon, 30 Oct 2017 01:53:54 -0000
Just to chime in on one point (and remembering that my responsibilities do not include telling working groups what to think), On Sun, Oct 29, 2017 at 3:25 AM, Eggert, Lars <lars@netapp.com> wrote: > Hi, > > On 2017-10-29, at 8:01, Simon Pietro Romano <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. > When we were discussing the QUIC charter, I was very reluctant to charter a new transport protocol in 2016 that didn't address multipath (other people have suffered more while adding multipath to a protocol that didn't anticipate multipath than I have, but I've seen enough suffering). That may be the point I pressed on most strongly while editing the current charter. So even though we wanted to minimize the initial charter scope, I included multipath in the charter I took to the IESG. I had assumed (without asking anyone) that - Enabling multipath and forward error correction extensions (listed as one of the key goals in the current charter) would put "making sure that extensions were possible" in scope for v1. I don't have an opinion about how "making sure" happens, of course. - If the working group was convinced that "greasing" in v1 is sufficient to enable extensions (at appropriate points in time), I would support that. - If the working group was convinced that something else is required, I'd listen, of course. Thanks, Spencer, speaking as responsible AD Lars >
- QUIC - Our schedule and scope Mark Nottingham
- Re: QUIC - Our schedule and scope Ian Swett
- Re: QUIC - Our schedule and scope Patrick McManus
- Re: QUIC - Our schedule and scope Salz, Rich
- Re: QUIC - Our schedule and scope Salz, Rich
- Re: QUIC - Our schedule and scope Eric Rescorla
- RE: QUIC - Our schedule and scope Lucas Pardue
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Willy Tarreau
- Re: QUIC - Our schedule and scope Göran Eriksson AP
- Re: QUIC - Our schedule and scope Mark Nottingham
- Re: QUIC - Our schedule and scope Mark Nottingham
- Re: QUIC - Our schedule and scope Mark Nottingham
- RE: QUIC - Our schedule and scope Mike Bishop
- Re: QUIC - Our schedule and scope Brian Trammell (IETF)
- RE: QUIC - Our schedule and scope Salvatore Loreto
- RE: QUIC - Our schedule and scope Roni Even
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Simon Pietro Romano
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Simon Pietro Romano
- Re: QUIC - Our schedule and scope Simon Pietro Romano
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Christian Huitema
- Re: QUIC - Our schedule and scope Colin Perkins
- Re: QUIC - Our schedule and scope Spencer Dawkins at IETF
- RE: QUIC - Our schedule and scope Mike Bishop
- Re: QUIC - Our schedule and scope Philipp S. Tiesel
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Martin Duke
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Olivier Bonaventure
- RE: QUIC - Our schedule and scope Lubashev, Igor
- Re: QUIC - Our schedule and scope Quentin De Coninck
- Re: QUIC - Our schedule and scope Ian Swett
- RE: QUIC - Our schedule and scope Lubashev, Igor
- Re: QUIC - Our schedule and scope Ian Swett
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Bernard Aboba
- Re: QUIC - Our schedule and scope Colin Perkins
- Re: QUIC - Our schedule and scope Joerg Ott