________________________________ From: Gautam Akiwate <[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? ... >> 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. --Ben
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
