Server should use lowest of Min-Downlink values, not last

[nickshanks]

A server should assume the bandwidth bottleneck is the (s)lowest of the various communications technologies in the end-to-end connection.

For example, say a browser knows it is connected to the internet solely via 802.11g, so sends a "MD: 54" header. The router knows it is connected to the WAN via ADSL2+ with a sync rate of 12224 Kbps, so appends a "MD: 12.2" trailer or modify the header to read "MD: 54, 12.2" if there's space in the packet. The ISP and other intermediaries ought not to modify the packets as they are most likely much much more capable. (This is assuming unencrypted transmission)

The receiving server should use 12 Mbps rather than 54 Mbps as the assumed maximum throughput of the client, and resolve the negotiation accordingly.

[IDisposable]

Should it rewrite the request and just replace the 54 with 12.2? Of course we can't change HTTPS or SPDY pipelined requests, so this is variable in behavior.

This points a very real weakness of MD in that the user-agent doesn't know the bandwidth of every hop. Perhaps we should just trust the user-agent's view of life and expect it to know the reasonable effective bandwidth available instead of putting optimistic caps on things.

This means that on the first request to a site in a certain context (e.g. on phone, using 3G) the user-agent would guess that bandwidth y is available and put that in the MD. After some packets are exchanged it could revise the estimate to be used for subsequent requests. A clever user-agent could store history by site and connection (including access-point names and connect class for WLAN and service providers for wireless-data) and estimate better for later use.

For SPDY pipelined requests, we're going to be the victim of server-side guessing... so we can possibly get a high-bandwidth version started and then the user-agent decides to ask for a lower one and normal cache-coherency will cause the cancellation of the optimistically-pipelined assets and request for new ones... sub-optimal, but better than where we are, and something to be aware of...

Another thing that MD brings up is cache pollution due to the possibly vast number of MD values that could be presented by a user-agent. Perhaps we should allow some form of binning/decimalization to ensure that caches can be asked to keep only a reasonable number of variants. While the final answer is what the server serves back in a response, we need to know what the rules are for reuse. Does a request with MD: 100 with a response of Vary: MD Content-MD: 6 satisfy a request for MD: 54?

Lastly, we need to consider information/history leakage if the user-agent is using history and current connection state to compute a MD value. What is an okay level of information to leak? What should a user-agent in Incognito mode do about history (initially none?) and connection information (lie, in what direction?)

[igrigorik]

@IDisposable the intent behind MD is to expose the same information as NetInfo API, which is the maximum downlink speed for last hop - nothing more, nothing less. For background, see https://github.com/w3c/netinfo/issues/13.

Cache fragmentation is contained to values specified in the NetInfo downlink speeds table. And no, Vary does not have the smarts to express "this response is good for XMbps+". For that, we need Key: http://igrigorik.github.io/http-client-hints/#rfc.section.2.2.2

@mnot any advice on language around handling multiple MD values? It feels like this should be deferred to UA's, with a recommended note that if multiple values are present, then pick the minimum?

[IDisposable]

Thanks tons for the information. I guess I should have had more context first :)

One question, http://igrigorik.github.io/http-client-hints/#rfc.section.2.2.2 gives the example

Key: MD;r=[0.384:]
Above example indicates that the cache key should be based on the MD header, and the resource should be cached and made available for any request whose advertised maxim downlink speed is 0.384Mbps (GPRS EDGE), or higher.

Would this be the typical realistic Key to emit? I would rather expect one specifying the upper-bound of the MD value instead of the lower-bound for reuse. My reasoning is that suppose the first user-agent requests MD: 12.2 and the server replies with a Key: MD;r=[12.2:] because it's nice and gens up a perfect match. Then the second user agent comes along and requests MD: 56, given the logic in the rfc, it would be perfectly valid for the cache to return the first response without ever asking the server for a higher resolution image. Am I right that the server really ought to be returning something (based on its own heuristics) like Key: MD;r=[12.2:55.9] or something if it wants to offer things at the breakpoint of 56?

[igrigorik]

@IDisposable see http://tools.ietf.org/html/draft-fielding-http-key-02#section-2.2.5. Yes, if you have particular "breakpoints", then you should emit appropriate parameter range indicators.