5 ms·

I was actually curious why SACK's don't resolve issue, but according to https://stackoverflow.com/questions/67773211/why-do-tcp-selective-acks-not-prevent-hol-b

I was actually curious why SACK's don't resolve issue, but according to https://stackoverflow.com/questions/67773211/why-do-tcp-selective-acks-not-prevent-hol-blocking-in-http-2 https://stackoverflow.com/questions/67773211/why-do-tcp-sele... > Even with selective ACK it is still necessary to get the missing data before forwarding the data stream to the application.

pi-e-sigma 3y ago
Which is exactly the same in HTTP2/3. You can't forward a stream when it's missing some data.
- afiori 3y ago
  I am curious of why the kernel does not allow it; there could be an API that gives you fragments of the stream in "events" like {slice: [10000, 10100], data:<blob>} and let the application have a peak preview of future data
- brickteacup 3y ago
  Yes, bytes from a *logical* stream need to be delivered in order. But in HTTP2 (3) multiple logical streams are multiplexed on top of one physical TCP (QUIC) connection. In the HTTP2 case this means that a dropped segment from logical stream A will block delivery of subsequent segments from an different logical stream B (which is bad for obvious reasons). QUIC doesn't have this problem, which is a large part of its value proposition.
  - pi-e-sigma 3y ago
    Except it doesn't work in practice and real world data proves it. Multiplexing streams inside of a single TCP connection don't magically make your data link less prone to dropped packets or high latency.
vasilvv 3y ago
It's possible to build something similar on top of TCP, see Minion [0] for an example. There are multiple reasons why this is less practical than building on top of UDP, the main two being, from my perspective: (1) this requires cooperation from the OS (either in form of giving you advanced API or having high enough privilege level to write TCP manually), and (2) this falls apart in presence of TCP middleboxes. [0] https://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs/ https://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs/
avianlyric 3y ago
Yes, TCP provides the guarantee that your application will always receive data in the same order it was sent. Your kernel will do the necessary buffering and packet reordering to provide that guarantee. So SACK might reduce packet resends, but it doesn’t prevent the latency hit that comes for having to waiting for the data went missing. Even if your application is capable of either handling out-of-order data, or is simply capable of handling missing data.

pi-e-sigma 3y ago

Which is exactly the same in HTTP2/3. You can't forward a stream when it's missing some data.

afiori 3y ago
I am curious of why the kernel does not allow it; there could be an API that gives you fragments of the stream in "events" like {slice: [10000, 10100], data:<blob>} and let the application have a peak preview of future data
brickteacup 3y ago
Yes, bytes from a *logical* stream need to be delivered in order. But in HTTP2 (3) multiple logical streams are multiplexed on top of one physical TCP (QUIC) connection. In the HTTP2 case this means that a dropped segment from logical stream A will block delivery of subsequent segments from an different logical stream B (which is bad for obvious reasons). QUIC doesn't have this problem, which is a large part of its value proposition.
- pi-e-sigma 3y ago
  Except it doesn't work in practice and real world data proves it. Multiplexing streams inside of a single TCP connection don't magically make your data link less prone to dropped packets or high latency.

vasilvv 3y ago

It's possible to build something similar on top of TCP, see Minion [0] for an example. There are multiple reasons why this is less practical than building on top of UDP, the main two being, from my perspective: (1) this requires cooperation from the OS (either in form of giving you advanced API or having high enough privilege level to write TCP manually), and (2) this falls apart in presence of TCP middleboxes. [0] https://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs/ https://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs/

avianlyric 3y ago

Yes, TCP provides the guarantee that your application will always receive data in the same order it was sent. Your kernel will do the necessary buffering and packet reordering to provide that guarantee. So SACK might reduce packet resends, but it doesn’t prevent the latency hit that comes for having to waiting for the data went missing. Even if your application is capable of either handling out-of-order data, or is simply capable of handling missing data.