> On Jun 3, 2025, at 6:21 AM, Ben Schwartz <[email protected]> > wrote: > > > From: Gautam Akiwate <[email protected] > <mailto:[email protected]>> > Sent: Monday, June 2, 2025 6:56 PM > > ... > > > 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. > > I don't think this is true. Each RR can have multiple "sla" values. > Presumably, server deployments would configure a number of RRs that reflects > the tiered structure of their service, and tag each RR with all the > applicable "sla" values. > > > 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? > > That seems reasonable to me. Perhaps you would like a SvcParam named > "background-priority" that overrides SvcPriority for "background" requests, > and is otherwise ignored? > That seems like it would simplify things quite a bit, but would not be extendable. That in itself is not bad, but is a shift from what we do now. I am not opposed to it. While we think through this, it might be helpful to see if there there are others who have thoughts on this issue. > ... > > >> 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? > > I think "background-priority" would make the expectations pretty clear. The > OS/client just has to determine if the request is "background", and adjust > the effective SvcPriority if so. > > It wouldn't provide any fancy latency-driven optimal selection behavior, but > it also would never be worse than the status quo.
Makes sense. Gautam > > --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]
