Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"
David Schinazi <dschinazi.ietf@gmail.com> Wed, 30 September 2020 22:08 UTC
Return-Path: <dschinazi.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 DCA8B3A0CCF for <quic@ietfa.amsl.com>; Wed, 30 Sep 2020 15:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 AtSAlk5cG-sK for <quic@ietfa.amsl.com>; Wed, 30 Sep 2020 15:08:46 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 AA6943A0CCD for <quic@ietf.org>; Wed, 30 Sep 2020 15:08:45 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id b22so4016180lfs.13 for <quic@ietf.org>; Wed, 30 Sep 2020 15:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9v7yfuMPbtVvJgN2AN35KV+iIiNDCiJLnPcXN/q58Eg=; b=SEHh0AdmFFaJLWcTRNEyYEpu0uZQxLilsBQytv9120srg/hf5lnYI6gP0EdxW+K9xo 5Du6aymNOkrmYsyBJHw6RU8WHZfbyqMcVV3AgnIgiN3zTT0Ll+6HLh0f4FUgL0gnTLhv otoI4gHdBD8A2ouxcjud+nFQOlvOkv7I7Ke1dnnlE/HPOWmsVaO19tWwq7IZzhexmu0t c1XIYa4FmlPJON8p/BJw3WbGLj5N5hiVb9Z3SP/5w52NY3VTx9KwF5YYl7IzQei1n5aQ 0LBWRvZCm6oE7jnWy4RqV+Yv3aDmC4zH6KvKoIN/mrRHo9cW8SkW74yBgRcCeRMIbOSu ZYaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9v7yfuMPbtVvJgN2AN35KV+iIiNDCiJLnPcXN/q58Eg=; b=crMOCoGjNxJVZ+jg0NFvXIp3maWWNQD/evklO+wj2Y8zbi+TY2yqyfUYYm0FDmGAzg MpfCNeZLHUWqQQxPWD0k0yFdI9/OXvbsOQT+Th62O0HZdyxQ/kFRTVrNsdca8o9JqWDI GowMecrSibGyjCSW0RoNCCgCNkYh6aBQxY3b8A1V3CBe6mJzK3kUlxVvrUe3yiZONPB/ nGXweKHUOQcppMsBJuyrXto528QANTm9zmkU75BAeW1IW13F4YB74gxRZqejZrTxfudy Egz77pJWwzO+oWofOvK24yDXkq/jxihjTaZ76u5jmk8RlVMVzvqOry+/kDjw59y877dV eawQ==
X-Gm-Message-State: AOAM530OtG3/mcH8kzbo1N6HOsTtprEeTOPzcAmpn6Gtl/W3w8uc8YyW gljOMsCsgbZTMtb9CTWYuM0wKJBIGGb9cyfeN/JwvKgE
X-Google-Smtp-Source: ABdhPJwmR0AJ97R9TZVTiOwOwN932jCXzyP/SHoPnZwmu27FuwuZiBYJ42HRitjnyTmVu4Se/j4pdn74XCWLX541Xzo=
X-Received: by 2002:ac2:4355:: with SMTP id o21mr1620933lfl.210.1601503723751; Wed, 30 Sep 2020 15:08:43 -0700 (PDT)
MIME-Version: 1.0
References: <5530E619-F6A8-4ECA-A9E9-3DE4B5DECA97@eggert.org> <a50d0abd-e7fd-164b-3249-8c50f37f1573@uclouvain.be> <CAKcm_gOXd=kMA8D5gsKK-3W8b2X9Rh3ywRCsy5v9NNXMM2TKYw@mail.gmail.com> <CAPDSy+5X7_j+6Sbb=Q9CpqhB5pb06s1Xp1n4aD1p7CEAygH1OQ@mail.gmail.com> <96a2f8ff-36e6-4ac3-b0b4-c4c0b4ba112e@www.fastmail.com>
In-Reply-To: <96a2f8ff-36e6-4ac3-b0b4-c4c0b4ba112e@www.fastmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 30 Sep 2020 15:08:32 -0700
Message-ID: <CAPDSy+5yCbQFBa6HE+1KMUEwBP9tYdTRvz1BD6C-fPV9--MUPQ@mail.gmail.com>
Subject: Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"
To: Martin Thomson <mt@lowentropy.net>
Cc: QUIC <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008f8bfb05b08f24be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/szIzDSgO0Bk6lubozjhML89g4ZE>
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: Wed, 30 Sep 2020 22:08:48 -0000
On Wed, Sep 30, 2020 at 2:35 PM Martin Thomson <mt@lowentropy.net> wrote: > Wasn't it of interest to the working group? I mean, a Google's interest is > relevant, but only to the extent that it contributed to the overall > interest in the feature. > Sure! I was just objecting to the existing text that overstated Google's involvement in multipath. Saying that there was WG interest sounds fine by me. David On Thu, Oct 1, 2020, at 02:21, David Schinazi wrote: > > To add to what Ian said, I really think that the following > > statement from the draft reply is an overstatement: > > <<[multipath support for QUIC] was part of the original > > charter due to its inclusion in the pre-IETF > > "Google QUIC" protocol>>. As Ian said, the team was > > considering it but it never made it into the protocol. > > Perhaps you could rephrase it to something like: > > <<[multipath support for QUIC] was part of the original > > charter because it was of interest to authors of the > > pre-IETF "Google QUIC" protocol>>? > > > > Other than that, the reply looks good to me, I think > > figuring out whether to do multipath in the WG, and > > refusing to remove encryption are the right calls. > > > > David > > > > On Wed, Sep 30, 2020 at 7:49 AM Ian Swett > > <ianswett=40google.com@dmarc.ietf.org> wrote: > > > > > > > > > On Wed, Sep 30, 2020 at 5:24 AM Olivier Bonaventure < > Olivier.Bonaventure@uclouvain.be> wrote: > > >> Lars, Lucas and Mark, > > >> > > > >> > FYI, below is a draft of our intended response to the Liaison > Statement "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group" > which we intend to send next week. > > >> > > > >> > Please feel free to send comments. > > >> > > > >> > Thanks, > > >> > Lars, Lucas and Mark > > >> > > > >> > -- > > >> > > > >> > Thank you for the update on your progress and your questions. > Please find our > > >> > responses below. > > >> > > > >> > On Qn-1: The future of multipath support for QUIC is currently > under active > > >> > discussion in the IETF QUIC working group. While it was part of the > original > > >> > charter due to its inclusion in the pre-IETF "Google QUIC" > protocol, several > > >> > > >> I'm very surprised by this sentence. It gives the impression that > > >> multipath was a feature of Google's proprietary QUIC protocol. My > > >> understanding based on the public documents that Google released and > the > > >> source code is that multipath was considered by Google as they > reserved > > >> one bit in the header to indicate multipath but that this was not > fully > > >> implemented nor tested within Google QUIC. If Google had a > specification > > >> of multipath QUIC, I'd be very interested in seeing this document. > > > > > > There was a design and part of an implementation, but it was never > completed because there were no customers for it and it added substantial > complexity. > > > > > > IETF QUIC has changed quite a bit from Google QUIC, so I think basing > any design on the more recent multipath > proposal(draft-deconinck-quic-multipath-05 < > https://tools.ietf.org/html/draft-deconinck-quic-multipath-05>) would be > a better starting point. > > >> > > >> My understanding of the initial charter discussion was that multipath > > >> was a desired feature by many of the participants in the initial > charter. > > >> > > >> > participants have argued during the last year that QUIC's > connection migration > > >> > support is sufficient for the majority of our use cases, and that > full-blown > > >> > support for multipath QUIC should consequently be abandoned as a WG > deliverable. > > >> > Other WG participants remain of the opinion that multipath support > for QUIC is > > >> > very important. Due to this active ongoing discussion, we do not > have an estimate > > >> > at this time whether WG drafts for multipath QUIC will be available > in 1Q2021. > > >> > > > >> > On Qn-2: The QUIC WG is chartered to provide an encrypted transport > protocol. > > >> > An option to disable encryption will hence not be standardized. > > >> > > > >> > Kind regards, > > >> > Mark Nottingham, Lucas Pardue and Lars Eggert, QUIC Working Group > chairs > > >> > > > >> > > >> Best regards, > > >> > > >> > > >> Olivier > > >> > >
- Draft response to Liaison Statement, "LS on ATSSS… Lars Eggert
- Re: Draft response to Liaison Statement, "LS on A… Magnus Westerlund
- Re: Draft response to Liaison Statement, "LS on A… Lars Eggert
- Re: Draft response to Liaison Statement, "LS on A… Olivier Bonaventure
- RE: Draft response to Liaison Statement, "LS on A… Flinck, Hannu (Nokia - FI/Espoo)
- Re: Draft response to Liaison Statement, "LS on A… Lars Eggert
- Re: Draft response to Liaison Statement, "LS on A… Spencer Dawkins at IETF
- Re: Draft response to Liaison Statement, "LS on A… Ian Swett
- Re: Draft response to Liaison Statement, "LS on A… David Schinazi
- Re: Draft response to Liaison Statement, "LS on A… Mikkel Fahnøe Jørgensen
- Re: Draft response to Liaison Statement, "LS on A… Martin Thomson
- Re: Draft response to Liaison Statement, "LS on A… David Schinazi