RE: flow control and DATAGRAM

["Lubashev, Igor" <[e-mail]>]

I think we are in an agreement here.  One design alternative is no flow control (only congestion control) for datagrams.  But in that case, the assertion below does not hold, since the second bullet is false for “poll/read”-based implementations (or any other implementation that is not based on “callback-on-network-receive-thread” model).

> ACK to a packet containing a DATAGRAM frame means:
> - The packet made it across the network to the QUIC endpoint on the other side
> - The QUIC implementation will deliver the DATAGRAM frame to application (it won't drop it locally)


  *   Igor

From: Christian Huitema <[e-mail]>
Sent: Monday, October 29, 2018 6:29 PM
To: Lubashev, Igor <[e-mail]>
Cc: Tommy Pauly <[e-mail]>; Jana Iyengar <[e-mail]>; Ian Swett <[e-mail]>; QUIC WG <[e-mail]>; Martin Thomson <[e-mail]>
Subject: Re: flow control and DATAGRAM


On Oct 29, 2018, at 2:28 PM, Lubashev, Igor <[e-mail]<mailto:[e-mail]>> wrote:
> ACK to a packet containing a DATAGRAM frame means:
> - The packet made it across the network to the QUIC endpoint on the other side
> - The QUIC implementation will deliver the DATAGRAM frame to application (it won't drop it locally)
>
> Does that make sense?

This only makes sense, if there is an effective flow control for DATAGRAMs.  The spec should be implementable by poll/read QUIC implementations as well as by callback-on-network-receive-thread implementations.  Unless there is an effective flow control, a buffering QUIC implementation must be able to discard DATAGRAMs, if the receiver app is not catching up.  The receiver would then have to ignore all non-DATAGRAM frames in that packet, since it would be unable to ACK the packet.  If the receiver is processing DATAGRAMs and STREAMs at different speeds, deliberate discards of packets containing DATAGRAMs would interfere with the congestion control, effectively HOL blocking STREAMs.

On the other hand, Datagram will be used to carry the media flows currently carried over RTP, and RTP does not include any kind of flow control.

The known weakness of RTP is the lack of integrated congestion control between data and media, do that a parallel data download can jeopardize  the quality of the real time media. But that's an argument for counting the datagrams in the congestion control window, not an argument for flow control.

There is an argument for controlling the rate at which media is sent. But that's typically done at the app layer, by negotiating codecs and compression parameters.

-- Christian Huitema