IETF Logo Mail Archive

Re: 2nd draft, response to Liaison Statement, "LS on ATSSS Phase 2Requirements to IETF QUIC Working Group"

David Schinazi <dschinazi.ietf@gmail.com> Thu, 01 October 2020 15:18 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 14ADA3A10F8 for <quic@ietfa.amsl.com>; Thu, 1 Oct 2020 08:18:09 -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 lMqCV8-f14zJ for <quic@ietfa.amsl.com>; Thu, 1 Oct 2020 08:18:07 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 489303A10C5 for <quic@ietf.org>; Thu, 1 Oct 2020 08:18:07 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id y11so7039660lfl.5 for <quic@ietf.org>; Thu, 01 Oct 2020 08:18:07 -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=R1SNFUkU2mNMsGyjkKDkEvY8M5EZU984yARrqstWgF0=; b=NFqCdPSJmHuqr090pLutIpFYj6tT6FtUyxVHYo4nmmF0+0ZmTctr4DgXePqSNvEWKD yXHULu7g3AjgJUPeEMRVJL2GtxvG6G9hACsY9jKwldFgT0krs39thoqF67VG08YT/ZZb q/sAdg014kj6Hk4XQPaZnoLgB1RzBX9yQ+bTqM5Q3kD5ORpDY+f+vP18dL4NIGw/Berf Wn2kaiuIz0YJeIuu4X1zJqlw2RiEkl9w1tnsut9ScZIdxy1Svk0tkkAhRc3/i2RgFl9M J3mm3TXEr9YQV86UHOshrOb7+IoD6s7onZhe4kvAZtNuaRXZ5jjhlbo7/f4LMAkK2Unb ujuw==
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=R1SNFUkU2mNMsGyjkKDkEvY8M5EZU984yARrqstWgF0=; b=ONHYvE0zq34eYukZ/uwGrsNxvUtHXqM1aiz+eaBDndzyAWbtzjqI1IlZx8bCjHFyFA eLMEn3JXrF/LyZZEF7k0oKRLRJfE7iQa+CjZuGOh3Jjap2Uq6s9lM8cYy5EIWw3t6khN wnRpXxLAmjH5uUrdFvfr0MIYplbAkAsXWOL4Qyf9+sLC5ldA5+tyIsydeF3HQ65Ft825 8eyS4XtGDrmlpd6JUlmjyzV10GxCme/cVM3VcAWvvyX2tvvmbHH4Eodvz7bWAK4+qn41 Pw35gGzi/RYMP0Ad/1Mx8yDF+z7ZWlv/oaFBKSXWp0YwXOlcHYl+r1ikJBMTz+WdS002 ovdg==
X-Gm-Message-State: AOAM531c7yiwo2ZG058yqQ4/ru8dbfc2q9utCBz4l5dvMAgMBgcqRLxL bpn/FmxnnlLejZK+NQCdiZlL44O22v6mEp0KqtFKwvzY
X-Google-Smtp-Source: ABdhPJwowjM/vUUsCZ5gvKm+rxkGCe4Rwm5cU/h8z/z77h0ZtCvDqwnUgtUIR623fy9pgt3T3qVf606ZikrL4tvLUwo=
X-Received: by 2002:a19:4319:: with SMTP id q25mr2444543lfa.505.1601565485437; Thu, 01 Oct 2020 08:18:05 -0700 (PDT)
MIME-Version: 1.0
References: <61E60D24-856D-44FF-B133-693FC9C40229@eggert.org> <CAKKJt-fH1oSTaEw6_L6b-bdJxWP7RB2iVgeErRu4KW4zCNhZzg@mail.gmail.com>
In-Reply-To: <CAKKJt-fH1oSTaEw6_L6b-bdJxWP7RB2iVgeErRu4KW4zCNhZzg@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 01 Oct 2020 08:17:54 -0700
Message-ID: <CAPDSy+5TvW9xLbY-RJk00zi5Sd4m1uu5mE3b1wqFAsQXETYZmg@mail.gmail.com>
Subject: Re: 2nd draft, response to Liaison Statement, "LS on ATSSS Phase 2Requirements to IETF QUIC Working Group"
To: Lars Eggert <lars@eggert.org>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d817c705b09d8529"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/kNdmmzZVT7FJ2e8TrVnrkpqoLlo>
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: Thu, 01 Oct 2020 15:18:15 -0000

Thanks Lars, the second draft looks good to me.

David

On Thu, Oct 1, 2020 at 7:36 AM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Hi, Lars,
>
> On Thu, Oct 1, 2020 at 6:20 AM Lars Eggert <lars@eggert.org> wrote:
>
>> Hi,
>>
>> thanks for the feedback! Below is an updated draft that attempts to
>> incorporate it.
>>
>> Please feel free to send further 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 being under active investigation for the pre-IETF "Google
>> QUIC"
>> protocol, several 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.
>>
>
> This is much improved.
>
> Perhaps it is also worth pointing out that (just like 3GPP) the IETF and
> QUIC working group are contribution-driven, so any timeline estimates
> depend on people contributing to the work, and the IETF is open to
> participation from anyone who can contribute to the work.
>
>
>> On Qn-2: The QUIC WG is chartered to provide an encrypted transport
>> protocol.
>> An option to disable encryption will hence not be standardized.
>>
>
> That's the right answer to the question the QUIC working group was asked.
> I agree that a different question might have gotten a different answer, but
> you're not a mind reader ...
>
> Best,
>
> Spencer
>
>
>> Kind regards,
>> Mark Nottingham, Lucas Pardue and Lars Eggert, QUIC Working Group chairs
>>
>>

v2.23.0 | Report a Bug | By Email