[DNSOP] Re: Comments on "Service Binding Mapping for Service Levels"

[Gautam Akiwate <[e-mail]>]

> On Jun 3, 2025, at 6:21 AM, Ben Schwartz <bemasc=[e-mail]> wrote:
> 
> 
> From: Gautam Akiwate <gakiwate=[e-mail] <mailto:gakiwate=[e-mail]>>
> 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 -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>