flow control and DATAGRAM

[Martin Thomson <[e-mail]>]

Hi Tommy,

Your slides - <https://github.com/quicwg/wg-materials/blob/master/ietf103/IETF103-QUIC-Datagram.pdf>
- say that DATAGRAM frames respect connection-level flow control.  I
missed that in the draft, and I don't know how they can do that in the
face of packet loss, especially when you don't necessarily retransmit
lost DATAGRAM frames.

For that to work, you would need a bunch more machinery to make the
connection-level flow control sync between endpoints in the case that
packets are lost.  A disagreement about how much flow control is used
causes things to break down badly.  Ian and I discussed this point at
the last meeting and quickly agreed that while it might be nice to
have flow control for this stuff, the increase in complexity is
considerable and (at the time) we thought it wouldn't be worth it.

The problem that introduces is that you could end up having too many
DATAGRAM frames arrive.  The receiver has to drop something at the
point that it can't handle them.  And we say that when you acknowledge
something, you processed it.  That's tricky.

It might be easier to say that a QUIC acknowledgment for a DATAGRAM
frame doesn't mean that it was received and processed by an
application.  An endpoint might discard these frames before passing
them on to applications if it doesn't have space.  In other words,
acknowledgment of DATAGRAM means that QUIC got it, not that the
application got it.  Sadly, that means that the QUIC acknowledgment
machinery doesn't help the application that uses DATAGRAM all that
much.  Also, the lower bound on reliability is 0, which isn't the best
thing ever.

Hard choices, I know.  I don't have a good design for maintaining
connection-level flow control (or any back pressure mechanism with
equivalent properties) that doesn't add both complexity and overhead.

Cheers,
Martin