Re: flow control and DATAGRAM

[Christian Huitema <[e-mail]>]

> On Oct 29, 2018, at 2:28 PM, Lubashev, Igor <[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