3 ms·

Could we speed the Internet up with more generic caching? I'd theorize that a decent percentage of all Internet traffic to residential ISPs is made up of HTTP

by Pyxl101 11y ago

Could we speed the Internet up with more generic caching? I'd theorize that a decent percentage of all Internet traffic to residential ISPs is made up of HTTP requests for highly cacheable resources. However, it seems like the mythical idea of an automatic caching HTTP proxy at the ISP level never really materialized. Perhaps that was possible in the HTTP days, but HTTPS makes it a challenge. How much better would Internet congestion be if there was a way for ISPs to cache commonly-referenced resources? They could even be video resources - if Netflix requests its videos across an HTTP connection by identifying a single common resource (a URL everyone will access who plays the video), then an ISP could simply cache the URL and serve it locally. It seems like HTTPS is a barrier to schemes like that. Instead of an ISP running a generic cache for commonly-referenced resources, each website provider needs to run a local POP that's trusted and knows just their content. (Though maybe Cloudflare like solutions are possible where the POP is not fully trusted.) If we set HTTPS aside for a moment, could we speed the Internet up with caching? How much of the traffic to saturated links are requests for the same content over and over again? Is there a conceptual way to achieve some of the privacy benefits from HTTPS while allowing an ISP to cache content in a generic way? Or could an ISP offer a discount for using HTTP traffic instead of HTTPS, and then cache content in a protocol-compliant way?

throwaway2048 11y ago
the entire point is ISPs are acting in bad faith looking for a payday, the limitations are not technical, but purely artifical rent seeking bullshit. They are not interested in solutions that do not involve paying them money.
Natanael_L 11y ago
I do think it could be neat with the support for a tag for "this is can be cached" in TLS streams, which could be applied to privacy unsensitive material, which identifies the ciphertext blob and thus lets the ISP tell the server sending it "I'm now going to cache this blob, tell every client on my network to use the same decryption key for this blob for X time and I'll hand them my cached copy". Presumably you'd have to use a signed hash of the ciphertext as the identifier, and decouple the encryption of these blobs from the rest of the TLS stream (use independent key material) to ensure it remains secure. But this way, any ISP that sees the same blob appearing frequently can chose to cache it automatically and quickly start saving bandwidth. Also, for maximizing privacy, I think this tag should be applied by the client only (can be disabled if you want to reduce metadata leaks) when the server tells the client "this particular data with identifier X can be auto-cached on the network level". One potential neat advantage here is that a LAN router/proxy could implement a cache for its own nodes by having the nodes send these cache requests directly to this router instead of letting the ISP see it, so you don't leak this metadata outside your own network.

by Pyxl101 11y ago

throwaway2048 11y ago

the entire point is ISPs are acting in bad faith looking for a payday, the limitations are not technical, but purely artifical rent seeking bullshit. They are not interested in solutions that do not involve paying them money.

Natanael_L 11y ago

I do think it could be neat with the support for a tag for "this is can be cached" in TLS streams, which could be applied to privacy unsensitive material, which identifies the ciphertext blob and thus lets the ISP tell the server sending it "I'm now going to cache this blob, tell every client on my network to use the same decryption key for this blob for X time and I'll hand them my cached copy". Presumably you'd have to use a signed hash of the ciphertext as the identifier, and decouple the encryption of these blobs from the rest of the TLS stream (use independent key material) to ensure it remains secure. But this way, any ISP that sees the same blob appearing frequently can chose to cache it automatically and quickly start saving bandwidth. Also, for maximizing privacy, I think this tag should be applied by the client only (can be disabled if you want to reduce metadata leaks) when the server tells the client "this particular data with identifier X can be auto-cached on the network level". One potential neat advantage here is that a LAN router/proxy could implement a cache for its own nodes by having the nodes send these cache requests directly to this router instead of letting the ISP see it, so you don't leak this metadata outside your own network.