Re: flow control and DATAGRAM

[Martin Thomson <[e-mail]>]

On Tue, Oct 30, 2018 at 7:01 AM Tommy Pauly <[e-mail]> wrote:
> I'm not suggesting any changes to when the packet gets ack'ed—specifically, I was responding to Martin's hypothetical of having an ACK to a DATAGRAM frame meaning that the application had processed the frame. My impression is that the 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)

That works.  If you allow for the possibility that an application that
is unable to process the DATAGRAM will be indistinguishable from QUIC
dropping it.  That is, if the application can't take the upcall
because it is too busy, then QUIC might not bother waiting.

> Having a separate outstanding data limit for the DATAGRAM "stream" is an interesting solution to the space. It would then have the nice property of not looking like traditional flow control. It could even be measured in number of frames, rather than bytes (depending on what the limiting factors are).

This is something I alluded to in my email.  I don't think that it
improves things much, other than perhaps insulating streams from the
excesses of DATAGRAM frames and vice versa.

If you have a limit, then you need to ensure that both endpoints agree
on its value eventually.  With DATAGRAM, you might think that it's
possible to add a new frame that expresses how much data was sent
(that is the sum of sizes of DATAGRAM frames).  That would run afoul
of reordering problems, where the limit is exceeded when delayed
DATAGRAM frames that are already counted, arrive after the accounting
frame.

You could limit the count to just lost DATAGRAM frames.  That would
allow a receiver to repair its view of how much was used.  However
that runs afoul of two problems: acknowledgments aren't reliable, and
packets can be declared lost and still delivered.  In both cases, the
sender can believe that frames didn't arrive and so increase their
report of "lost bytes" too much.  The receiver ends up with an
inflated view of what was consumed (as opposed to the value being
short).

If you wanted to solve this problem, you would probably need to have
per-frame tracking, which makes this a lot less lightweight than I
think we want.