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?
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.