Bandwidth dependent asset delivery about cdn HOT 2 CLOSED

Having looked into this as part of #8, I don't it's practical to implement a bandwidth measurement interface. Because browsers don't send that information to the server, this would have to be calculated on the server using a second HTTP request, using something along the lines of:

1. Client pings CDN URL 1
2. CDN stores current timestamp, redirects user to CDN URL 2 (appending a unique hash)
3. Client pings CDN URL 2
4. CDN does a lookup on the hash, calculates the difference between the current timestamp and stored timestamp for that hash, obtaining the time it takes for a round-trip between client and server
5. CDN delivers the resource based on the value obtained

The problem with this, apart from the added complexity of tying two HTTP requests together to deliver a single resource (what happens if CDN URL 1 hits a different instance than CDN URL 2?), the value extracted from the routine described above isn't representative of the available bandwidth.

I'm not an expert on TCP by any stretch, but I do know that it has some mechanisms in place precisely because it has no idea about how much bandwidth will be available when a connection is started.

One of those mechanisms, called "slow-start", makes the connection start with a very limited bandwidth, which grows exponentially over time until it detects (using a congestion avoidance mechanism) that it has used all the bandwidth it can.

In practice, this means that the only way to (more or less accurately) predict the bandwidth available for the transfer of a 1.5MB image is to send a dummy 1.5MB image across the wire and measure the bandwidth at peak transfer time, which of course is unpractical.

There were numerous attempts to introduce a browser-level API to provide this information (see this, this and this) without really getting anywhere, one of the reasons precisely being how difficult it is to measure available bandwidth.

My suggestion is that until an API is standardised and browsers are able to calculate and provide this information as part of the request, we park this.

/cc @jimlambie

from cdn.

I agree completely, thank you for the thorough response!

We'll close this one for now. If the future arrives, we can revisit.

from cdn.