draft-gakiwate-dnsop-svcb-sla-parameter proposes a new SVCB SvcParam, "sla=0,1,2" indicating whether an endpoint is suitable for "background", "interactive", and/or "realtime" use.
The proposal is well-formed as a matter of SVCB syntax, but I have some questions about the design. 1. SLA is well-known as "service level agreement". Are you sure you want to use that name? 2. The document explains that this parameter is necessary because there are scenarios where a service with a single hostname needs to be used by both "background" and "interactive" clients What are those scenarios? None are mentioned. Note that SVCB records are specific to a "service" such as an HTTP "origin", including the URI scheme, not just a "hostname". Why not use distinct origins for distinct performance characteristics? 3. It seems like this is primarily geared toward cases where the lowest-latency nodes are not preferred for latency-insensitive use. Why not? Usually, we prefer lowest latency for all connections. (I imagine this is because the lowest-latency nodes might be approaching a load limit or have higher marginal cost for utilization.) 4. Are you sure that these 3 categories will be sufficient indefinitely? In my experience, multipurpose traffic steering can grow to cover more than 3 traffic classes. 5. Standardization is principally relevant in an "open" deployment, where components from separate vendors must interoperate. Do you imagine a deployment where the client and service are developed by separate parties? If they are developed by the same party, any setup can be done by private arrangement. 6. Respecting this flag is potentially adverse to the client's interest (degrading the service level it uses, and potentially delaying the connection if one is already open for a different service level). Are you sure clients will respect this indicator, which does not appear to be enforced by any technical mechanism? 7. Sharing the origin for multiple service levels adds complexity to connection establishment and pooling. Have you considered how this interacts with HEv3? --Ben Schwartz
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
