Re: Updated DATAGRAM -03 draft

[Robin MARX <[e-mail]>]

Hello Tommy,

Good to see the updated draft.
I do wonder about the decision to enforce congestion control for DATAGRAM
frames and the effect this will have on the gaming use case.
As also discussed in Prague, real-time gaming often requires a set update
rate frequency (e.g., 30-60 messages per second) for responsiveness.
I wonder if congestion controlling the frames (e.g., delaying/dropping
them) will produce some weird edge cases that really mess with this setup.
It's a bit difficult to assess because the messages are usually relatively
small (though they could be mixed with larger messages, e.g., RPCs) and you
could make the argument that, if there is actual congestion, the packets
will be dropped in the network either way.
You could also say that custom game-focused implementations will just
ignore the text and do their own logic as needed.

So I'm not sure the text needs changes, I just wanted to mention that it
might not be optimal for the real-time gaming use case and that it might be
capable footgun with some weird edge cases if people do stick to the text.

With best regards,
Robin


On Wed, 10 Jul 2019 at 18:30, Nick Banks <nibanks=
[e-mail]> wrote:

> 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]> 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]> 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]
>
> *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]>, David Schinazi <
> [e-mail]>, Tommy Pauly <[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
>
>
>
>
>


-- 

Robin Marx
PhD researcher - web performance
Expertise centre for Digital Media

T [phone] - GSM [phone]

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05