> On Jun 2, 2025, at 7:20 AM, Ben Schwartz <[email protected]> > wrote: > > > From: Gautam Akiwate <[email protected] > > <mailto:[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.
Ack. > > > 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". Currently, as defined in the draft the server can publish multiple SVCB RRs (each with a different “sla” value) with the OS filtering down to the correct SVCB RR based on the request service level. With the 0-255 range, we are implicitly asking the OS to go through ~250 SVCB RRs if we expect a server to use the entire range for different OSes etc. Instead of expanding the range that drastically, we can get rid of the labels (“background” etc) and just have a numeric range with the lower numbers indicating lower cost and maybe lower performance. We then leave the specifics of how a client can request a specific service level for its network request to the OS. As an example, we can state how traffic classes can be used by the OS to map the request appropriately with the default going to the highest defined value. > > Also, the draft's use of "realtime" does not match any CDN architecture I've > encountered. Yeah. It was us adding a third class to accommodate for future. But the background vs not background would be the primary use case. If anything, this fact seems to be an argument for just two classes for now? Overall, I do not feel comfortable having a large range of values. Without corresponding server infrastructure with a significantly different cost and performance profile to map to, I fear we end up re-inventing traffic classes. > ... > > > 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. Do you think going to be a numeric range combined with leaving the specifics to the OS of how a client can request a specific service level achieve get to this? If a client/OS wanted to support this they could allow an application to mark their requests accordingly? > > > 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. Ack. > > --Ben > _______________________________________________ > DNSOP mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
