Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt

[Bob Harold <[e-mail]>]

On Thu, Jul 5, 2018 at 3:31 PM Tom Pusateri <[e-mail]> wrote:

>
>
> On Jul 5, 2018, at 2:49 PM, Bob Harold <[e-mail]> wrote:
>
>
> On Thu, Jul 5, 2018 at 2:02 PM Tom Pusateri <[e-mail]> wrote:
>
>>
>>
>> On Jul 5, 2018, at 1:39 PM, Bob Harold <[e-mail]> wrote:
>>
>> I have concern:
>>
>> 3. DHCPv6 Encapsulating Options
>>
>> "There is no order
>> implied by the order of options sent or received. It is up to the
>> receiving client to determine which order to use the DNS server
>> configurations."
>>
>> Let's not wait for some non-standard way to decide the order. Please add
>> 'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" now, like
>> in MX and SRV records.
>>
>>
>> Willem has said that from experience with Stubby, that the client should
>> determine the order it uses the discovered DNS servers. The network
>> operator advertising the list doesn’t necessarily have real time data to
>> determine response times, delays, etc. I’m happy to discuss this more. Why
>> should the network operator dictate this?
>>
>> I would think that the network operator, who can set the option per
> subnet, would have a better idea where the subnet is, than a client machine
> that roams from place to place and usually does not know where it is
> located.  If the operator lists more than one server, there is likely to be
> a need to designate primary vs backup in some cases.  If the client knows
> better, it can certainly have its own list, and ignore or append what the
> network recommends.  But the network knows better what will be faster or
> even reachable from a given subnet, in my opinion.  (I run the DHCP servers
> at my location, so I am probably biased.)
>
>
> Since the option is probably only refreshed once per day on average, the
> list is fairly static. Assuming that an on subnet server will respond
> faster than a server several hops away is a bad assumption. It depends on
> many factors and these will change constantly depending on the number of
> clients, the number of TLS connections the server can manage, number of
> switches and congestion at the network level including APs, etc. Since
> these conditions change at the sub-second level, having the client figure
> out which server responds best seems more flexible.
>
> If all the servers in the list should respond, does the network operator
> care which one is used? Once you get past the access point, is there
> typically congestion in the wired network you’re trying to avoid?
>
> I’ll put this on my slides to discuss in Montréal.
>
> Thanks,
> Tom
>
> Thanks for the discussion.  If the client tries them all from time to time
and picks the fastest, that is probably best.  I was assuming that most
clients would be fairly simple-minded and use the first one, and only try
the next if the first failed.  For simple clients, an order might be
helpful.  (Some IOT devices have very limited computing power.)

I would be interested in what others think.  Sorry I cannot attend Montreal.

-- 
Bob Harold