On Sat, Jun 23, 2018 at 1:23 PM Ben Schwartz <bem...@google.com> wrote:
> On Sat, Jun 23, 2018 at 6:51 AM Shumon Huque <shu...@gmail.com> wrote: > >> On Sat, Jun 23, 2018 at 12:00 AM Shumon Huque <shu...@gmail.com> wrote: >> >>> In other threads, Erik Nygren suggested that we review the proposed >>> DNS record for HTTP Alternative Services draft: >>> >>> https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02 >>> (You might also want to read RFC7838 for background). >>> >> >> Another comment on this draft: >> >> I noticed that RFC7838 says: >> >> The Alt-Svc field value can have multiple values: >> >> Alt-Svc: h2="alt.example.com:8000", h2=":443" >> >> So, presumably my example in the last message was not quite correct >> for representing multiple target hosts for the service: >> >> Instead of: >> >> _443._https.example.com. 900 IN ALTSVC "h2=\"cdn1.example.org:443\"" >> _443._https.example.com. 900 IN ALTSVC "h2=\"cdn2.example.org:8443\"" >> >> It probably is: >> >> _443._https.example.com. 900 IN ALTSVC "h2=\"cdn1.example.org:443\", >> h2=\"cdn2.example.org:443\"" >> >> >> It also says: >> >> When multiple values are present, the order of the values reflects >> the server's preference (with the first value being the most >> preferred alternative). >> >> The preference order of the values does not permit load balancing. >> So, if a site wants to do load balancing, as many do today, I assume >> they would have to employ only one target hostname, with multiple address >> records, >> > > It seems to me that a site could publish multiple ALTSVC RRs, each of > which could contain multiple targets. > Thanks. I agree that it could - it just wasn't clear to me if the spec intended to prohibit it or not. If RFC7838 permits only one ALTSVC field in the HTTP header or HTTP2 frame (does it?), then does that also mean this field has to be expressed in just one ALTSVC DNS RR ... and still rely on random/shuffle ordered return of the address >> record set from name resolution functions. >> > > At the stage of processing ALTSVC responses, we are talking about new > client logic, so the significance of ordering is up to us. The draft is a > bit hazy on this point, but we could add an explicit requirement that > clients shuffle the ALTSVC RRSET before processing it. Would that help? > Yes, I think many DNS protocol engineers would be happy with that outcome. If applications are no longer assuming RRset response order shuffling on the part of DNS servers, then we can could go back to the pure notion that RRsets are inherently unordered (eventually). In this sense, SRV is more >> flexible since it supports both priority and proportional load balancing. >> > > Yes, that's true. So far, no one has asked us for this kind of explicit > percentage load-balancing. However, because the format is extensible, we > can add it later as a new Alt-Svc parameter. > I guess this is a question worth discussing with the web community (or other application communities that might contemplate using ALTSVC). Thanks! Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
