From nobody Fri Sep 24 09:46:50 2021 Return-Path: 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: In-Reply-To: From: David Schinazi Date: Fri, 24 Sep 2021 09:46:28 -0700 Message-ID: Subject: Re: WGLC for Datagram Extension To: Spencer Dawkins at IETF Cc: Lucas Pardue , QUIC WG , QUIC WG Chairs Content-Type: multipart/alternative; boundary="000000000000cde95d05ccc07dad" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2021 16:46:47 -0000 --000000000000cde95d05ccc07dad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 > 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 dependi= ng >> on how you look at it < >> https://datatracker.ietf.org/doc/html/rfc9000#section-19.8>. >> > > 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 carefull= y, > so your pointer was super helpful). > > I did see a couple of places where the STREAM frame type was using plural= s > (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-dat= agram-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 =F0=9F=99=82) > > 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 ? >> >> 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), bu= t >>> I'm still looking at the datagram draft, and noticed something odd. Cou= ld >>> 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-d= atagram-frame-type >>> talks about "the datagram frame type" (singular) - even the section hea= der >>> 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 f= ield, >>> 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 Sectio= n >>> 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-b= ehavior-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 invit= ing >>> 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 >>> 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 m= ailing >>>>>> 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 w= hen 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 re= turn >>>>> 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 change= s 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 QUI= C >>>> DATAGRAM frames and it includes multiplexing [1]. The working group's = 00 >>>> draft started with a single variable-length integer multiplexing ident= ifier >>>> called the Flow ID. After some fruitful WG implementation and discussi= on, >>>> in draft 01 it switched to an identifier tuple (Quarter Stream ID, Con= tenxt >>>> 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 frame= s for >>>> their own precise needs and purpose. >>>> >>>> Cheers, >>>> Lucas >>>> >>>> [1] - https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram >>>> >>> --000000000000cde95d05ccc07dad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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> wro= te:
Hi, David,=C2=A0

=
On Thu, Sep 23, 2021 at 6:53 PM David= Schinazi <dschinazi.ietf@gmail.com> wrote:
Hi Spencer,

Ye= s, your interpretation is correct. The language about whether it's inte= rchangeably one frame type or two=C2=A0frame types mirrors RFC 9000's d= efinition of the STREAM frame which is also one or eight frames depending o= n how you look at it <https://datatracker.ietf.org/doc/htm= l/rfc9000#section-19.8>.

Thank you for the background here (I was watching the base QUIC drafts, bu= t spent a lot of time looking at diffs, rather than re-reading carefully, s= o your pointer was super helpful).=C2=A0

I did see= a couple of places where the STREAM frame type was using plurals (for exam= ple,=C2=A0https://www.rfc-editor.org/rfc/rfc9000.html#nam= e-stream-frames, plural,=C2=A0 versus=C2=A0https://www.ietf.org/archive/id/draft-ietf-quic-datagram-0= 4.html#name-datagram-frame-type, singular), so I included that in the P= R. I swear, if I wasn't looking for the second datagram frame type in t= he second called "datagram frame type", I wouldn't have notic= ed anything=C2=A0=F0=9F=99=82)

And it really was a= couple of small changes. Thanks for considering my comments.
Best,

SPencer
=C2=A0
Regar= ding your editorial comments, could I ask you to send them our way as a PR = to <htt= ps://github.com/quicwg/datagram>=C2=A0?

Thanks,
David

On Thu, Sep 23, 2021 at 4:33 PM Spencer Dawki= ns at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, L= ucas,

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 ha= t back on for a moment?=C2=A0

From the Introductio= n:=C2=A0

This document defines two new DATAGRAM= QUIC frame types, which carry application data without requiring retransmi= ssions.

And most of the= document about "datagram frame types" (plural), but pretty much = all of=C2=A0https://www.ietf.o= rg/archive/id/draft-ietf-quic-datagram-04.html#name-datagram-frame-type= talks about "the datagram frame type" (singular) - even the sect= ion header uses the singular phrasing, along with the caption to Figure 1.= =C2=A0

I understand what the document=C2=A0is sayi= ng, to be=C2=A0
  • there are two datagram frame types,=C2=A0= 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 le= ngth field, and=C2=A0
  • otherwise, whatever this document says about = "datagrams" is true for both datagram frame types.
= Is that about right?=C2=A0

I can dig that ou= t from the document, but if that was clearer in Section 4 - "Datagram = Frame Types", and a couple of clarifying sentences, that might be a bi= t 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).= =C2=A0

As long as I'm still typing, I might me= ntion one other thing - I searched for the string "reliabl" in th= e draft, and there are 24 occurrences, which is fine, although=C2=A0perhaps= repetitive, until you get down to=C2=A0https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html#n= ame-behavior-and-usage, which says=C2=A0

When = an application sends an unr= eliable datagram over a QUIC connection, QUIC will generate a new DA= TAGRAM frame and send it in the first available packet. This frame SHOULD b= e 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 opt= ion, but (after 20 occurrences explaining that all datagrams are unreliable= ), maybe this is just inviting confusion.=C2=A0

Th= anks for considering my comments, of course. Do The Right Thing!
=
Best,

Spencer

<= div class=3D"gmail_quote">
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:5= 2 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Lucas and Matt,

On Thu, Sep 16, 2= 021 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 Unrel= iable Datagram Extension to QUIC", located at:
=C2=A0 https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html=

Please take time to review it carefully and raise any remaining iss= ues you see either on the GitHub repo issues list[1] or on this mailing lis= t.

I've re-read the discussio= n in=C2=A0https://github.com/quicwg/datagram/issues/6, and now better un= derstand the points of view that resulted in the lack of datagram multiplex= ing in this specification (I was following that discussion when it was happ= ening, but hindsight during re-reading helped a lot!)

<= div>I especially appreciate the addition of the text in https://www.ietf.org/archive/id/draft-ietf-qui= c-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 o= f multiplexing at the transport layer, and agree that holding this specific= ation up while that experience is gathered, would not be The Right Thing To= Do.=C2=A0

I'm aware of at least two "RTP= over QUIC" proposals that assume that they'll need to multiplex d= atagrams, 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 re= questing publication of -04 (modulo any changes that pop up in WGLC, of cou= rse).=C2=A0

Thanks for yo= ur 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]. Th= e working group's 00 draft started with a single variable-length intege= r multiplexing identifier called the Flow ID. After some fruitful WG implem= entation and discussion, in draft 01 it switched to an identifier tuple (Qu= arter Stream ID, Contenxt ID). I'd say that we're still figuring ou= t exactly how the things the __use__ datagrams, want to use datagrams. I th= ink it's too early to understand the right common transport solution at= this time, and that leaving it undefined does not prevent people from usin= g datagram frames for their own precise needs and purpose.

Cheers,
Lucas

[1] - <= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram" t= arget=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-masque-h3-data= gram
--000000000000cde95d05ccc07dad--