Re: WGLC for Datagram Extension

David Schinazi <dschinazi.ietf@gmail.com> Fri, 24 September 2021 16:46 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 414973A0FD1; Fri, 24 Sep 2021 09:46:46 -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 Cx0vNKZkE_yE; Fri, 24 Sep 2021 09:46:41 -0700 (PDT)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 DC8A73A0FCC; Fri, 24 Sep 2021 09:46:40 -0700 (PDT)
Received: by mail-pf1-x42b.google.com with SMTP id g14so9417226pfm.1; Fri, 24 Sep 2021 09:46:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U7b6pQmMovUis8F53UeZ+r9FfEVVdnaduv+TdUQHVWI=; b=jacp7rFRRwBeIj4jnl2jHKZvMqBV4u3d9ALa1dGr7kDmCOnm+ohMcKCbDDu8/tflgC Z5tl3Leus4zUVPm0lRyqn/lIYxPjPAx5F/GsiiC1mMB16mt8xt7plHIgiLk1Em4E7xvy vACuOlMutjeNjt9rxZgjMiqUFtT2Y8pJJhhu1OeNVYoxuhbO+WXBvXJe3Mdvhr7yFqo/ cBPFGw88ap/DrX0UZM4t8Og5noOhAUrOwjN9rdhM3TLr0/Y+94y79f2j3OiLKKJ8W0tL oIF3+IY6mI//mXAhZMiso3AoqdbL4O6A6oeP28Jz8wVNUPo2BG3zxPcAAKmRqrNolY1d Q5Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U7b6pQmMovUis8F53UeZ+r9FfEVVdnaduv+TdUQHVWI=; b=PxdrnPwTZMWyGVk8iz45r8BhTv5TpeDA1brE2JGrg8thXxAXB9sOttDSgNDy/ol80Y As7RA2WJMb4WgrCWJjSn112TzCAMhxONNOj0PsxWyIc1ka85IvgGcf/jTlL2WyAy+1lx AbmZEH6xCHO+W/rDcDi8Qvi7qa7G/8Huuq2W5U46tT3MLCLcKuU8QXkNhDGiSqLnykuS /QfvYxpXNbqb+6Xyhy6QERIPSU1lbCM3qeAs8x/q00I7y5ppHieh5z6MfgcEFq90x72w DprCY50X7qOHaoXGKbrBQnk1dW5LeJh3EA6R2yMtLb1thzy7nHHQa0J2EdUpBEqJpuTz SIlg==
X-Gm-Message-State: AOAM531UqkZ5fw2cK2/3NqIn2UBscshJhL39XuXXij4Yl0zhGQFj2mYv +d0EyBM4OefRh59zf3LQ2Gd4ajZw2Ln/gxfuzudw0SNF
X-Google-Smtp-Source: ABdhPJzvrP6SFn/5b5LYCUTlM66dUgKnkwn2ZOsSieOdb8WLzvnCw01LslHcGDhTjzTR1yJmh5RHvOxAzvi1njuLmms=
X-Received: by 2002:a62:1786:0:b0:445:1a9c:952a with SMTP id 128-20020a621786000000b004451a9c952amr10663647pfx.39.1632501999983; Fri, 24 Sep 2021 09:46:39 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9oaZ4L_yJPhm11Gym8Rxc0nq6H=mCpLGsH_eMGVHer0uEA@mail.gmail.com> <CAKKJt-eDmpNX4EE73s0nm0X8rrXXz1GpEup22Zfu4KDYVsmRmA@mail.gmail.com> <CALGR9obyy0gmWrnmzrWaM-Cjgp1ofNTnN7Y+QbwU2u37mZU_ig@mail.gmail.com> <CAKKJt-enVHks1F-yvh9_bEKkP0znY+5m-hjVpS_sR7A5SNsFiw@mail.gmail.com> <CAPDSy+5k7xO-UEBq7eTg1nTzsTx6-=kPqMVjNDoAbUSKa3-ipQ@mail.gmail.com> <CAKKJt-dG9inej0GU0ZWHJBORgzz35870Dhbm0EWQjjaFY7ig0g@mail.gmail.com>
In-Reply-To: <CAKKJt-dG9inej0GU0ZWHJBORgzz35870Dhbm0EWQjjaFY7ig0g@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Fri, 24 Sep 2021 09:46:28 -0700
Message-ID: <CAPDSy+7CPrPwkOj5f8RJ+SoeTCt04_udiK8Wdbg-WY1MiL7RwA@mail.gmail.com>
Subject: Re: WGLC for Datagram Extension
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, QUIC WG <quic@ietf.org>, QUIC WG Chairs <quic-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cde95d05ccc07dad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/RrEdEGHJikvhw_URM_KIHrieMmk>
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: Fri, 24 Sep 2021 16:46:47 -0000

Thanks Spencer! I've approved the PR - we can merge it at the end of WGLC
assuming no one objects.

David

On Thu, Sep 23, 2021 at 6:08 PM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Hi, David,
>
> On Thu, Sep 23, 2021 at 6:53 PM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>> Hi Spencer,
>>
>> Yes, your interpretation is correct. The language about whether it's
>> interchangeably one frame type or two frame types mirrors RFC 9000's
>> definition of the STREAM frame which is also one or eight frames depending
>> on how you look at it <
>> https://datatracker.ietf.org/doc/html/rfc9000#section-19.8>gt;.
>>
>
> Thank you for the background here (I was watching the base QUIC drafts,
> but spent a lot of time looking at diffs, rather than re-reading carefully,
> so your pointer was super helpful).
>
> I did see a couple of places where the STREAM frame type was using plurals
> (for example,
> https://www.rfc-editor.org/rfc/rfc9000.html#name-stream-frames, plural,
> versus
> https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html#name-datagram-frame-type,
> singular), so I included that in the PR. I swear, if I wasn't looking for
> the second datagram frame type in the second called "datagram frame type",
> I wouldn't have noticed anything 🙂)
>
> And it really was a couple of small changes. Thanks for considering my
> comments.
>
> Best,
>
> SPencer
>
>
>> Regarding your editorial comments, could I ask you to send them our way
>> as a PR to <https://github.com/quicwg/datagram> ?
>>
>> Thanks,
>> David
>>
>> On Thu, Sep 23, 2021 at 4:33 PM Spencer Dawkins at IETF <
>> spencerdawkins.ietf@gmail.com> wrote:
>>
>>> Hi, Lucas,
>>>
>>> I'm top-posting to say that I'm not talking about multiplexing
>>> datagrames now (except to thank you and Christian for your replies), but
>>> I'm still looking at the datagram draft, and noticed something odd. Could
>>> you put your working group chair hat back on for a moment?
>>>
>>> From the Introduction:
>>>
>>> *This document defines two new DATAGRAM QUIC frame types, which carry
>>> application data without requiring retransmissions.*
>>>
>>>
>>> And most of the document about "datagram frame types" (plural), but
>>> pretty much all of
>>> https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html#name-datagram-frame-type
>>> talks about "the datagram frame type" (singular) - even the section header
>>> uses the singular phrasing, along with the caption to Figure 1.
>>>
>>> I understand what the document is saying, to be
>>>
>>>    - there are two datagram frame types, 0x30 and 0x31
>>>    - the only difference between these two datagram frame types is that
>>>    datagram frames with frame type 0x30 do not include a length field, while
>>>    datagram frames with frame type 0x31 do contain a contain a length field,
>>>    and
>>>    - otherwise, whatever this document says about "datagrams" is true
>>>    for both datagram frame types.
>>>
>>> Is that about right?
>>>
>>> I can dig that out from the document, but if that was clearer in Section
>>> 4 - "Datagram Frame Types", and a couple of clarifying sentences, that
>>> might be a bit easier for the reader (and, of course, for the various
>>> review teams that will be looking at this document for the first time
>>> during IETF Last Call).
>>>
>>> As long as I'm still typing, I might mention one other thing - I
>>> searched for the string "reliabl" in the draft, and there are 24
>>> occurrences, which is fine, although perhaps repetitive, until you get down
>>> to
>>> https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html#name-behavior-and-usage,
>>> which says
>>>
>>> When an application sends an unreliable datagram over a QUIC
>>> connection, QUIC will generate a new DATAGRAM frame and send it in the
>>> first available packet. This frame SHOULD be sent as soon as possible, and
>>> MAY be coalesced with other frames.
>>>
>>>
>>> Could "unreliable" be dropped from the first sentence? It would belong
>>> there if reliable datagrams were an option, but (after 20 occurrences
>>> explaining that all datagrams are unreliable), maybe this is just inviting
>>> confusion.
>>>
>>> Thanks for considering my comments, of course. Do The Right Thing!
>>>
>>> Best,
>>>
>>> Spencer
>>>
>>> On Thu, Sep 23, 2021 at 1:12 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
>>> wrote:
>>>
>>>> Hi Spencer,
>>>>
>>>> On Thu, Sep 23, 2021 at 6:52 PM Spencer Dawkins at IETF <
>>>> spencerdawkins.ietf@gmail.com> wrote:
>>>>
>>>>> Hi, Lucas and Matt,
>>>>>
>>>>> On Thu, Sep 16, 2021 at 3:35 PM Lucas Pardue <
>>>>> lucaspardue.24.7@gmail.com> wrote:
>>>>>
>>>>>> Hello QUIC WG,
>>>>>>
>>>>>> This email starts the Working Group Last Call for "An Unreliable
>>>>>> Datagram Extension to QUIC", located at:
>>>>>>   https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html
>>>>>>
>>>>>> Please take time to review it carefully and raise any remaining
>>>>>> issues you see either on the GitHub repo issues list[1] or on this mailing
>>>>>> list.
>>>>>>
>>>>>
>>>>> I've re-read the discussion in
>>>>> https://github.com/quicwg/datagram/issues/6, and now better
>>>>> understand the points of view that resulted in the lack of datagram
>>>>> multiplexing in this specification (I was following that discussion when it
>>>>> was happening, but hindsight during re-reading helped a lot!)
>>>>>
>>>>> I especially appreciate the addition of the text in
>>>>> https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html#name-multiplexing-datagrams
>>>>> .
>>>>>
>>>>> I accept the wisdom of getting more experience with various people
>>>>> using application-defined multiplexing in various ways before adding any
>>>>> flavor of multiplexing at the transport layer, and agree that holding this
>>>>> specification up while that experience is gathered, would not be The Right
>>>>> Thing To Do.
>>>>>
>>>>> I'm aware of at least two "RTP over QUIC" proposals that assume that
>>>>> they'll need to multiplex datagrams, so I won't be surprised if we return
>>>>> to this question in the future, but for now, the chairs are Doing The Right
>>>>> Thing, and I support requesting publication of -04 (modulo any changes that
>>>>> pop up in WGLC, of course).
>>>>>
>>>>
>>>> Thanks for your comments.
>>>>
>>>> Chair hat off, speaking as an individual. To add to the examples, the
>>>> MASQUE working group is working on a draft to define HTTP's use of QUIC
>>>> DATAGRAM frames and it includes multiplexing [1]. The working group's 00
>>>> draft started with a single variable-length integer multiplexing identifier
>>>> called the Flow ID. After some fruitful WG implementation and discussion,
>>>> in draft 01 it switched to an identifier tuple (Quarter Stream ID, Contenxt
>>>> ID). I'd say that we're still figuring out exactly how the things the
>>>> __use__ datagrams, want to use datagrams. I think it's too early to
>>>> understand the right common transport solution at this time, and that
>>>> leaving it undefined does not prevent people from using datagram frames for
>>>> their own precise needs and purpose.
>>>>
>>>> Cheers,
>>>> Lucas
>>>>
>>>> [1] - https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram
>>>>
>>>