RE: Updated DATAGRAM -03 draft

[Nick Banks <[e-mail]>]

My preference would also be to support flow control for the IDs. Though, I still think that the IDs by themselves have merit. As Tommy has said, you can think of a datagram ID on a given connection as pretty much the same thing as a UDP port for an IP address. If both sides know before hand what port to use, everything is fine.

- Nick

From: QUIC <[e-mail]> On Behalf Of Tommy Pauly
Sent: Wednesday, July 10, 2019 9:12 AM
To: Ian Swett <ianswett=[e-mail]>
Cc: QUIC WG <[e-mail]>
Subject: Re: Updated DATAGRAM -03 draft




On Jul 9, 2019, at 6:22 PM, Ian Swett <ianswett=[e-mail]<mailto: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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-pauly-quic-datagram-03.txt&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793956874&sdata=Vi6tqg74ZTl5s%2BG5aU1v4R4dHbSbweBuz2vSBYn6sIU%3D&reserved=0>
Status:         https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-pauly-quic-datagram%2F&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793961863&sdata=hDx9XfQUXu5YgfkzStkR47J5dYYjSeoEJH4hhj9RFsk%3D&reserved=0>
Htmlized:       https://tools.ietf.org/html/draft-pauly-quic-datagram-03<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-pauly-quic-datagram-03&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793966856&sdata=fPeG461Z1OEpy2z5vgyptHWZTghaDfLLqtlByAfQN%2FA%3D&reserved=0>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pauly-quic-datagram<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-pauly-quic-datagram&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793971846&sdata=%2F5BpNnlBfTjXJKcIXPw0AtSI4ZnR5ANBy0dI8uKkhFw%3D&reserved=0>
Diff:           https://www.ietf..org/rfcdiff?url2=draft-pauly-quic-datagram-03<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-pauly-quic-datagram-03&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793976837&sdata=gEChkKf0lX7YYGBeMKiZPOKsN8LNerq3HURRpmzNfDc%3D&reserved=0>

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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793981824&sdata=voffvGDVz3PluwcN5wuAZqtflBE9zgk%2FD6wt2rfNU0M%3D&reserved=0>.

The IETF Secretariat