Re: Updated DATAGRAM -03 draft

[Tommy Pauly <[e-mail]>]

> On Jul 9, 2019, at 6:22 PM, Ian Swett <ianswett=[e-mail]> wrote:
> 
> Thanks Tommy.  As I've expressed before, I'm not a big fan of the ID field(now flow identifiers) unless they have clear transport level functionality.

Understood! 
> 
> Adding signaling for opening and closing these flows seems like a stronger reason to add these IDs to the transport layer.  Have you considered splitting this draft into two or the frame type into two and making the version with a flow identifier more full-featured?
> 

That's certainly an option. As it stands, the frame type with a Flow ID is already a different type value. I think if people decide that the datagrams are mainly useful with the extra signaling being part of the transport layer, then I'd prefer to just do that in this document, but if not, then it can be separate.

Overall, I see a few different options for handling flow IDs:

- Remove them from the DATAGRAM transport altogether
- Support flow IDs in the DATAGRAM draft with more explicit tie-ins to the transport, like flow lifetime management
- Have a separate draft specifying how the next layer above the QUIC transport should manage multiplexing of datagram flows, by putting identifiers at the start of datagram payloads, and using reliable control stream(s) to negotiate lifetimes of flows

Thanks,
Tommy

> On Mon, Jul 8, 2019 at 11:20 AM Tommy Pauly <tpauly=[e-mail] <mailto:[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
>> 
>