Handling DNS-SD services updates by the controller

[kkasperczyk-no]

Problem

Currently the controller is getting DNS-SD services from the accessory device by manually triggering this action with resolve command. However there might be several cases (at least I see 2) when some of the data in the advertised records changed and controller should be aware of that:

1. Accessory device changed IP address
2. SED accessory device changed polling interval and thus CRA/CRI values too.

If the controller will not update this information it might result in communication failures.
I would like to discuss and figure out the solution on how should the controller update such information. I see several options, like:

• Triggering manually resolve once again when we are aware of the changes. That might be useful in the test scenarios, but not in the final implementation.
• Calling resolve by the controller periodically that would provide it with the most recent information. That is easy to implement, but not effective (it can resolve all the time data that never changed) and also refreshing interval may turn out to be too big, so failures will be observed anyway.
• Calling resolve by the controller after the first failure. The idea would be that if something went wrong controller pulls the most recent data just in case, as it might help to solve the problem. That should be also easy to implement and quite error-proof, but there might be some cases that controller will use old data, because there will be no failures. For example SED could decrease poll intervals, so it can respond more often, but controller will not be aware of that and still use the old bigger values.
• Using unsolicited mDNS advertisements that according to RFC: https://datatracker.ietf.org/doc/html/rfc6762#section-10.2 should be advertised by the mDNS responder. In theory if responder would send it and controller could handle those messages it would be the most effective way of updating services data. Nevertheless it seems to be the most complex solution and I'm not aware if this should be currently working and also if the Thread Border Router would be able to support it.

Proposed Solution

[kkasperczyk-no]

@LuDuda @Damian-Nordic @andy31415 @tcarmelveilleux @bzbarsky-apple @msandstedt any thoughts on that? Please add to discussion anybody who could be interested in it.

[Damian-Nordic]

I think 3rd option is the minimum we must do as the behavior is required by the spec. Also, the controller should periodically invalidate the cached values according to the TTL of the DNS records. I'm not sure, however if 4th option is required by the spec or not.

[bzbarsky-apple]

Right, third option is a minimal bar. Once we have that in place, we can think about 4th option....

[msandstedt]

We have some prototypes that use chip::Controller::DeviceController from the sdk and some where we've rolled our own.

Where we've rolled our own controller object, we've used a variant of option 3. Our variant is that we have a dedicated (polling) keepalive read and, when this hits a failure threshold, we resolve and establish a new session. We will likely move from a polling keepalive to a subscription-based keepalive because this has nice semantics for this type of thing.

Either way, these approaches are very similar to option 3 and seem to work well.

Option 4 also sounds great and very sophisticated, but it seems risky to assume broadcast of unsolicited advertisements. I assume such an approach would likely still have to be done in conjunction with option 3.

In summary, yes I also agree that implementing option 3 makes sense right now.

[kkasperczyk-no]

Thanks for sharing your opinion, I also think that 3rd option is the best for the first shot.

[kkasperczyk-no]

@pan-apple FYI