Re: Updated DATAGRAM -03 draft

[Tommy Pauly <[e-mail]>]

We had a productive lunch meeting for Datagram today after the QUIC session (with Lars, ekr, Martin Thomson, Lucas Pardue, David Schinazi, Eric Kinnear, Nick Banks, and Tommy Pauly in attendance).

The group agreed that the relevant open issue was the use of flow IDs in the transport. The decision we came to collectively was to:

- Remove Flow Identifiers from the QUIC DATAGRAM (transport) draft. Specify that each application is responsible for defining its datagram flow management scheme.
- David will be creating a new document to define how HTTP/3 marks and uses DATAGRAM frames.

I have opened a Pull Request to remove flow IDs from the draft here: https://github.com/tfpauly/draft-pauly-quic-datagram/pull/11

While this may get merged, we don't plan to submit a new version of the draft until the new HTTP/3 draft has been written.

Best,
Tommy

> On Jul 8, 2019, at 11:20 AM, Tommy Pauly <tpauly=[e-mail]> wrote:
> 
> Hello all,
> 
> We’ve updated the QUIC DATAGRAM draft to incorporate some of the feedback we received at the side meeting in Prague. Notably, it clarifies:
> 
> - Guidance around datagram acknowledgements
> - Datagrams do not participate in any flow control
> - Datagrams do participate in congestion control
> 
> The remaining area of open discussion is around the newly re-named optional “flow identifiers”. The primary argument for removing these is that applications can add identifiers onto datagrams themselves, and the transport should not transmit a field that it does not do anything with. We did add some text clarifying that these identifiers are essentially like UDP ports for demultiplexing, and pointed out some *minimal* things the transport can do to help batch transmission of datagrams in the same flow and promote fate-sharing within a flow. There’s been some discussion on Slack of other approaches that would make these flow IDs more first-class citizens—adding reliable signaling for opening and closing flows, as many applications would also generally need some similar sort of control channel—but these seem a bit heavy-weight. Either way, this is an area where discussion is welcome and I expect the document to change.
> 
> Best,
> Tommy
> 
>> Begin forwarded message:
>> 
>> From: [e-mail] <mailto:[e-mail]>
>> Subject: New Version Notification for draft-pauly-quic-datagram-03.txt
>> Date: July 6, 2019 at 6:30:01 PM PDT
>> To: Eric Kinnear <[e-mail] <mailto:[e-mail]>>, David Schinazi <[e-mail] <mailto:[e-mail]>>, Tommy Pauly <[e-mail] <mailto:[e-mail]>>
>> 
>> 
>> A new version of I-D, draft-pauly-quic-datagram-03.txt
>> has been successfully submitted by Tommy Pauly and posted to the
>> IETF repository.
>> 
>> Name:		draft-pauly-quic-datagram
>> Revision:	03
>> Title:		An Unreliable Datagram Extension to QUIC
>> Document date:	2019-07-06
>> Group:		Individual Submission
>> Pages:		8
>> URL:            https://www.ietf.org/internet-drafts/draft-pauly-quic-datagram-03.txt <https://www.ietf.org/internet-drafts/draft-pauly-quic-datagram-03.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/ <https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/>
>> Htmlized:       https://tools.ietf.org/html/draft-pauly-quic-datagram-03 <https://tools.ietf.org/html/draft-pauly-quic-datagram-03>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pauly-quic-datagram <https://datatracker.ietf.org/doc/html/draft-pauly-quic-datagram>
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pauly-quic-datagram-03 <https://www.ietf.org/rfcdiff?url2=draft-pauly-quic-datagram-03>
>> 
>> Abstract:
>>   This document defines an extension to the QUIC transport protocol to
>>   add support for sending and receiving unreliable datagrams over a
>>   QUIC connection.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
>