> From: Gautam Akiwate <[email protected]> ...
> For instance, consider an application like weather that fetches data in the > background but then when in the foreground wants to use more optimal end > points. The application might want to use a slower server to save on costs > for background traffic and reduce the loads and costs on the interactive edge > servers. This seems like a good example that would improve the draft. It also demonstrates that the primary intended use case is one in which the client and server are developed by a single entity, and the standard allows the OS to offer a convenience that make implementation easier for this entity. > There is some potential confusion here. The three classes were supposed to > map to three performance profiles for servers. A cost-effective server in a > data center (background), an edge location (interactive), and a performant > edge cache at the ISP edge cache perhaps (real-time). The many different > traffic classes should map to one of these three different profiles. For > instance, bestEffort and responsiveData could map to the interactive server > class. Do you think calling the three classes something other than > background, interactive, and real-time might reduce confusion? I don't think the proposed "3 fixed classes" is a good framework. In the primary use case, it is the OS that must choose among these options, so it might be more sensible for the distinction to match something known to the OS, like "onscreen/offscreen/scheduled". Otherwise the OS must perform a (potentially lossy) mapping to service levels, or the client must configure such a mapping. Different OSes may have different concepts for app states, etc. Also, some apps may wish to use this mechanism in ways that involve details of their server infrastructure. To support the broadest use, I would recommend an IANA registry with a Specification Required range and a Private Use range, plus edge-case semantics like "0 = default" and "255 = unknown". Also, the draft's use of "realtime" does not match any CDN architecture I've encountered. ... > While it is likely that the choice of server is co-related with latency it is > not always. The choice on the server side will primarily driven by cost. Yes, but suppose the "less expensive" option also has lower latency for a particular user (e.g. a user who happens to be near the data center). Should that user choose the higher-cost option? If not, it might be better to signal the cost hierarchy and let the client use latency to find the Pareto-optimal server. > Also, we do not currently connection pool requests to the same origin with > different traffic classes. In general, anything that impairs connection pooling creates a significant performance and cost risk. The same applies to cache hit rates. As a result, dividing connections into separate tiers in this way is likely to increase both cost and latency in many use cases. Some warning text may be appropriate. --Ben
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
