Re: QUIC Datagram Discussion

[Colin Perkins <[e-mail]>]

> On 13 Nov 2018, at 15:44, Ian Swett <ianswett=[e-mail]> wrote:
> 
> I agree with Jana and Martin's comments.  Adding an on-the-wire ID is adding complexity and wire overhead with no clear value.  As Martin said, it’s also not clear what a recipient is supposed to do with it?

The recipient uses it to demux datagrams, much like it uses the stream ID to identify and demultiplex streams. The complexity at the QUIC layer is small, and it greatly simplifies many applications, and the demultiplexing of applications, to have this functionality as a common feature. 

> If you want to add an application level ID, you should do it in the application mapping.

It needs to be in the QUIC datagram layer, since it is common to want to demux different applications sent on a single connection. That is, we’re trying to avoid having to use mechanisms like that in RFC 7983 within QUIC, by providing the demultiplex at the datagram layer in a single, application-independent, way.

> And congestion control within congestion control is even scarier.

The suggestion was not congestion control within congestion control, but rather providing mechanisms to allow differential congestion control for sub-flows as a possible future extension. Such behaviour is widely implemented in the types of applications that use datagram service, and we have examples of how to do it in the IETF (e.g., draft-ietf-rmcat-coupled-cc-07, which has been stuck in the RFC Editor’s queue for some months now).

> Using sender side ids to allow an application to be notified of receipt or loss(even if it’s not guaranteed to deliver it to the application) is a completely reasonable idea, but that's part of the API, not part of the DATAGRAM frame.

It’s not clear what you mean by ‘sender side ids’. If the receiver is to be able to detect loss of datagrams, then we need sequence numbers in the DATAGRAM frames, and to expose those sequence numbers in the datagram API. Many applications need that functionality. 

Colin



> On Tue, Nov 13, 2018 at 1:44 AM Martin Thomson <[e-mail] <mailto:[e-mail]>> wrote:
> This.  Keep it stupidly simple.  Also, I don't understand what the
> *recipient* of a DATAGRAM_ID would do with that.  Maybe I should wait
> for an actual write-up.
> On Tue, Nov 13, 2018 at 5:38 PM Jana Iyengar <[e-mail] <mailto:[e-mail]>> wrote:
> >
> > Thanks for sending the notes along.
> >
> > FWIW, I would be very wary of going into separate ID spaces with DATAGRAMs. Separating congestion control within a connection is problematic -- you want scheduling priorities, but you do not want to do two different controllers within the same connection. I also think dragons be there, like with flow control; keeping this simple is going to be key in getting this done..
> >
> > - jana
> >
> > On Tue, Nov 13, 2018 at 4:26 AM Mikkel Fahnøe Jørgensen <[e-mail] <mailto:[e-mail]>> wrote:
> >>
> >> And eventual consistency algorithms where multiple servers chatter to reach consensus but where data loss is not essential. This could be an example where retransmission with low priority is of interest because another server probably already sent the old data. New data is more interesting.
> >>
> >> On 12 November 2018 at 22.21.25, Mikkel Fahnøe Jørgensen ([e-mail] <mailto:[e-mail]>) wrote:
> >>
> >> Another use case is voting consensus algorithms were M/N must approve within a deadline. I suspect the current datagram proposal is sufficient for that.
> >>
> >>
> >>
> >> On 12 November 2018 at 22.18.06, Mikkel Fahnøe Jørgensen ([e-mail] <mailto:[e-mail]>) wrote:
> >>
> >> Hi Tommy,
> >>
> >> I think game location data is also important. This might be sent at a relatively low frequency. In some cases with a fixed frequency like say 30Hz and not very sensitive to latency, in other cases 30Hz on average, but depending on user input and highly sensitive to latency.
> >>
> >> Also perhaps a grouping into high volume / low volume and latency sensitive and latency tolerant.
> >>
> >> There might also be cases where retransmission is of interest, but with low priority that doesn’t block head of line. I can’t think of any use cases right now.
> >>
> >> Other use case could be human interface for automation control which is similar to the game use case except people are more likely to get hurt. For example drone control input and drone position feedback.
> >>
> >>
> >> Kind Regards,
> >> Mikkel Fahnøe Jørgensen
> >>
> >>
> >> On 12 November 2018 at 22.07.45, Tommy Pauly ([e-mail] <mailto:[e-mail]>) wrote:
> >>
> >> Hello QUIC,
> >>
> >> Last week, several of us who were interested in fleshing out the use cases and details for unreliable frames in QUIC met up in an informal side meeting.
> >>
> >> I took notes there, and wanted to share them with the whole list for documentation’s sake. Please feel free to respond with any other thoughts or opinions you may have!
> >>
> >> Best,
> >> Tommy
> >>
> >> =========================
> >>
> >> What are the use cases that would be interested in unreliable QUIC?
> >>
> >> General interest in real time media, bundled with reliable transport. Sensor reading
> >> VPN use case of making things look like web traffic, but allow tunneled packet to be sent unreliably
> >> Realtime audio/video (bidirectional like RTC Web, unidirectional streaming)
> >> WebRTC over QUIC
> >> Video conference, augmented reality, single transport for media and data.. Current spec for AR has synchronization problem.
> >> HTTP/WebSocket/Datachannel servers currently have multiple connections that could be just one
> >> Centralized conferencing in WebRTC
> >> Signaling traffic (mobile core network, high signaling load)
> >> Measurement traffic being multiplexed with data
> >> 5G wifi/cellular link multi-path control for datagrams
> >> Use QUIC as a TURN relay into the CDN
> >> Consolidating reverse proxy
> >>
> >>
> >> Should work as an extension QUIC (v1)
> >> Minimal or no changes to how applications handle datagram payload and sending
> >>
> >> Don’t need to support fragmentation of datagrams in QUIC, just make sure that the frame boundaries are supported. Application on top generally fragments if necessary.
> >>
> >> Application must be able to introspect maximum datagram size for the datagram channel
> >>
> >> Try to accommodate different use cases with sensible support if possible
> >>
> >> Should DATAGRAM frames be ACKed?
> >>
> >> Yes. Would applications use it? Helps know what to encode next, for example.
> >>
> >> ACKs may need different scheduling algorithms for DATAGRAMs
> >>
> >> No flow control; but rate control. Could delay ACKs to help determine rate of consumption to influence rate of sending, packet pacing
> >>
> >> Can there be multiple ID spaces for DATAGRAM frames?
> >>
> >> Draft currently says no, but suggestion at meeting was to introduce a DATAGRAM_ID
> >>
> >> DATAGRAM_ID could be used to set different congestion control per datagram “flow”
> >> Different queues to deliver to application
> >> Different priorities
> >> Should be a VLI
> >> Handles bundling of RTP vs RTCP, or multiple RTP streams
> >>
> >> DATAGRAM_IDs are a different namespace from STREAM_IDs. They do not have equivalents such as RESET_DATAGRAM_ID, MAX_DATAGRAM_DATA, DATAGRAM_DATA_BLOCKED, MAX_DATAGRAM_IDS, or DATAGRAMS_BLOCKED.
> >> Separate even and odd for which side initiated? But can always send in any direction without the other side opening it.
> >>
> >> Upon migration or any connection ID length change, signal that maximum datagram size changed
> >>
> >>
> >> Can we pass up ICMP errors for a given DATAGRAM?
> >>
> >> Can send DATAGRAMs in 0-RTT
> >>
> >> Add congestion window consideration—sending “immediately” still respects congestion control
> 



-- 
Colin Perkins
https://csperkins.org/