Re: flow control and DATAGRAM

[Roberto Peon <[e-mail]>]

Such per-frame tracking could be a single bit if the protocol using DATAGRAM is willing to do windowed updates (i.e. 1 in flight at once) of such things.
-=R

On 10/29/18, 3:52 PM, "QUIC on behalf of Martin Thomson" <[e-mail] on behalf of [e-mail]> wrote:

    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.