Re: [quicwg/base-drafts] Discuss Application-Limited Sending (#1637)

[Nick Banks <[e-mail]>]

nibanks commented on this pull request.



>  
    OnPacketAckedCC(acked_packet):
      // Remove from bytes_in_flight.
      bytes_in_flight -= acked_packet.bytes
      if (InRecovery(acked_packet.packet_number)):
        // Do not increase congestion window in recovery period.
        return
+     if (IsAppLimited())
+       // Do not increase congestion_window if application limited.
+       return

This gets into implementation specifics a bit, but I don't think the pseudocode can be as trivial as this.

Naively, if this function is called for two different packets in a row, without a corresponding send operation being performed between them, then only the first `OnPacketAckedCC` ever actually increases `congestion_window` because the previous call just decremented `bytes_in_flight` and incremented `congestion_window` guaranteeing that `IsAppLimited()` will always return false for future packets.

In a slightly more intelligent interpretation of this, where you actually preform this logic for all the bytes acknowledged in a whole ACK frame in a single call, you can still have the same problem if you end up processing two ACK frames back to back before you end up doing a send. I have some ideas on how to solve that (at least for my implementation) but I was wondering if this should be mentioned (if not pseudocoded) here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1637#pullrequestreview-144148863