4 ms·

I'm not as excited about this as I was for HTTP/2 . Every benchmark I've seen is <5% performance improvement. I've heard the difference is larger on cellular n

I'm not as excited about this as I was for HTTP/2 . Every benchmark I've seen is <5% performance improvement. I've heard the difference is larger on cellular networks with packet loss but haven't seen examples. What we need more than HTTP/3 is ESNI. Exposed server names are a real security risk.

bawolff 5y ago
If you're looking at benchmarks without packet loss, then i'm not sure what you expect. Http/3 is almost entirely about that situation. ESNI is totally unrelated. People can work on more than one thing.
- throwaway189262 5y ago
  Unrelated but a ton of work is being put into HTTP/3 while ESNI has been lingering in draft spec for years. As far as protocol work, I think their priorities are wrong. Most wireless protocols hide packet loss from upper layers anyways using retry/FEC. I can't think of a common situation where wireless packet loss is even visible to layer 4, so efforts to build tolerance to it are usually pointless
  - bawolff 5y ago
    Sure, but would the people working on http/3 be otherwise working on ESNI? Its a different problem space requiring different skills. > Most wireless protocols hide packet loss from upper layers anyways using retry/FEC. I can't think of a common situation where wireless packet loss is even visible to layer 4, so efforts to build tolerance to it are usually pointless Its attempting to build tolerance to sudden transient latency spikes interacting badly with congestion control algorithms. You can hide packet loss, you can't hide some random packet taking a lot longer to be delivered due to having to be retried.
    - throwaway189262 5y ago
      > Its attempting to build tolerance to sudden transient latency spikes interacting badly with congestion control algorithms. You can hide packet loss, you can't hide some random packet taking a lot longer to be delivered due to having to be retried. Good point. By using UDP you can get around head-of-line blocking. I didn't consider that

bawolff 5y ago

If you're looking at benchmarks without packet loss, then i'm not sure what you expect. Http/3 is almost entirely about that situation. ESNI is totally unrelated. People can work on more than one thing.

throwaway189262 5y ago
Unrelated but a ton of work is being put into HTTP/3 while ESNI has been lingering in draft spec for years. As far as protocol work, I think their priorities are wrong. Most wireless protocols hide packet loss from upper layers anyways using retry/FEC. I can't think of a common situation where wireless packet loss is even visible to layer 4, so efforts to build tolerance to it are usually pointless
- bawolff 5y ago
  Sure, but would the people working on http/3 be otherwise working on ESNI? Its a different problem space requiring different skills. > Most wireless protocols hide packet loss from upper layers anyways using retry/FEC. I can't think of a common situation where wireless packet loss is even visible to layer 4, so efforts to build tolerance to it are usually pointless Its attempting to build tolerance to sudden transient latency spikes interacting badly with congestion control algorithms. You can hide packet loss, you can't hide some random packet taking a lot longer to be delivered due to having to be retried.
  - throwaway189262 5y ago
    > Its attempting to build tolerance to sudden transient latency spikes interacting badly with congestion control algorithms. You can hide packet loss, you can't hide some random packet taking a lot longer to be delivered due to having to be retried. Good point. By using UDP you can get around head-of-line blocking. I didn't consider that