1

The HTTP/3 spec states that

because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was directly impacted by the lost packet

While I understand this in the context of cumulative ACKs, I had assumed that selective ACKs would prevent a stall as they allow

the receiver to acknowledge discontinuous blocks of packets which were received correctly

But clearly this isn't the case as per the quote from the HTTP/3 spec above. So, my question then is why does head-of-line blocking persist even with discontinuous acknowledgements?

Paul Carey
  • 1,768
  • 1
  • 17
  • 19

1 Answers1

1

Even with selective ACK it is still necessary to get the missing data before forwarding the data stream to the application. Applications expect from TCP a continuous data stream and there is no mechanism to deal with temporary holes which get latter filled. All what selective ACK allow is to communicate that already received data don't need to be resend again but that only the outstanding data (the hole in the stream) need to be resend.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • But if there’s just a hole in the stream wouldn’t that affect just one of the http/2 streams instead of all of them? – Paul Carey May 31 '21 at 14:23
  • 2
    @PaulCarey: The application sees only the TCP stream, i.e. the data in order. It has no access to any data which are already acknowledged but which come after unacknowledged data. And even if it would be able to access these data there might be relevant information in the hole which concern the interpretation of the already acknowledged data. Contrary to this UDP is a message protocol (not a byte stream protocol) and each UDP message can be interpreted by its own. – Steffen Ullrich May 31 '21 at 14:45