Re: WGLC for Datagram Extension

Christian Huitema <huitema@huitema.net> Thu, 23 September 2021 19:45 UTC

Return-Path: <huitema@huitema.net>
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 CD8B23A199E for <quic@ietfa.amsl.com>; Thu, 23 Sep 2021 12:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 E7dXPpLLwEis for <quic@ietfa.amsl.com>; Thu, 23 Sep 2021 12:45:45 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BCC3A199A for <quic@ietf.org>; Thu, 23 Sep 2021 12:45:45 -0700 (PDT)
Received: from [66.113.192.7] (helo=xse.mail2web.com) by mx134.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mTUf6-0000n0-9O for quic@ietf.org; Thu, 23 Sep 2021 21:45:43 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4HFlyC2l2Wz9qJ for <quic@ietf.org>; Thu, 23 Sep 2021 12:45:39 -0700 (PDT)
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mTUf5-0003g2-8K for quic@ietf.org; Thu, 23 Sep 2021 12:45:39 -0700
Received: (qmail 12924 invoked from network); 23 Sep 2021 19:45:38 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.0]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic-chairs@ietf.org>; 23 Sep 2021 19:45:38 -0000
To: Lucas Pardue <lucaspardue.24.7@gmail.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: QUIC WG <quic@ietf.org>, QUIC WG Chairs <quic-chairs@ietf.org>
References: <CALGR9oaZ4L_yJPhm11Gym8Rxc0nq6H=mCpLGsH_eMGVHer0uEA@mail.gmail.com> <CAKKJt-eDmpNX4EE73s0nm0X8rrXXz1GpEup22Zfu4KDYVsmRmA@mail.gmail.com> <CALGR9obyy0gmWrnmzrWaM-Cjgp1ofNTnN7Y+QbwU2u37mZU_ig@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Subject: Re: WGLC for Datagram Extension
Message-ID: <9af47a96-2db3-4eae-c672-ac5260185792@huitema.net>
Date: Thu, 23 Sep 2021 12:45:37 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <CALGR9obyy0gmWrnmzrWaM-Cjgp1ofNTnN7Y+QbwU2u37mZU_ig@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.192.7
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.192.0/27
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.0/27@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCMn8 MUOZLpEUmHbCMQfz2s3mD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaqlHdH9stIYSUOP2ajLGtTxQ6V51u76v35b1wNe/MvdIN+Yj9 JT+HIE3AciYbXmyy2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkFDWJmcqHKssKxaylFamaV+b9tZ+C5y Oc2YAGkaEP1NO+wd68fWg8M/DqNJnyxK7mcdCu2mlibEyS19RfuR8H5R17NirEYyqwqMBGrw8ELi qOyD7UxtOMuKFjzK5zsiVohMBqzR52YHar/IFGqdBj1a6IupC5RqLj/k6/wmh+zu68PH12Bh87aa 4YfZs104p87OifVovUq7COge14oi3y0trSOIPpeqwlm2NDGXIJ2x7EtekSh8Zhx/YtERKbWN8E65 bJwwfOCWa1Hfd26B3Yz3qlEK3+u/ASce4nQ4h7L8KMIeGq4RRh5M7nLD0EqYqp3AsH8oBeNW4xIL 14PLVrot99CwkyNW5oJ+r5LYXcMk4hEVniihuDwEGDcmr6e3OPRQ28Zj66SD4p3NmXFnx4KfNEag CyVPq75vi41Z9pV0nKF0ncK/IbQSxSNB5qs1OjFEY8m+dvJolEdXjj+kQUhP2NYc49bpBvCc7Zkb MKX9sb13qFZSq8Fx+9otn0aqja8VKPqpdskk5LxBR/9t1zMMkdu6/R2FM84kxYRFSvC1IDg1BRW7 hzp8w3iHcOwbVtsmWfnQGGis4EvbR3jXsI0ESXwhBU2hwt/J18C+HygJl/jEzm1SsR8v3aJbN/NZ fa8pHhHaz+HPa0HAgEx4sWDF
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/GcPc7XdQmJjIbCKSv5KSfNBtkGc>
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, 23 Sep 2021 19:45:50 -0000

On 9/23/2021 11:11 AM, 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 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.

Another possibility is to use FEC with Datagrams. If an application does 
that, it could very well apply FEC before demuxing.

Or, use segmentation/reassembly of datagrams to mitigate MTU issues. 
Again, if an application does that, it could very well process a 
reassembly header before any demuxing.

Or, use both segmentation/reassembly and FEC.

And of course, if the application needs to stick a flow-id in front of 
the datagram packets, it can do that easily, no transport support needed...

-- Christian Huitema