Re: [dnssd] Adoption call for draft-sctl-advertising-proxy

[Jonathan Hui <[e-mail]>]

On Thu, Aug 12, 2021 at 7:59 AM Ted Lemon <[e-mail]> wrote:

> This is exactly the discussion I think we want to have.
>
> With a single SRP server, this is a non-problem: the SRP First-Come,
> First-Served Naming mechanism guarantees that if the same client registers
> twice, it will be recognized the second time and its update will supersede
> the previous registration, rather than conflicting with it.
>
To address the case where a device may transition between Thread and Wi-Fi
networks, having the device leverage SRP regardless of whether the device
is connected via Thread or Wi-Fi would also resolve any conflicts that
might occur. Fortunately, SRP on Wi-Fi is something that you're already
addressing with draft-tljd-dnssd-zone-discover.

> With multiple SRP servers, we have a problem because the SRP client might
> register with a different SRP server the second time, since it has no idea
> it's connected to the same infrastructure (and indeed the SRP server
> contact mechanism may be different, so that which server is updated is
> non-deterministic or just not under the client's control). In this case,
> we'll see a conflict when the second update comes in.
>
> The way I'm currently proposing to address this is by requiring SRP
> replication when there is more than one SRP server, and by not renaming,
> but rather waiting for the conflict to resolve. With SRP replication, we
> can use FCFS naming to see that it's actually the same client doing the
> update, so there's no conflict at the SRP level. The only conflict is in
> mDNS. When the SRP update propagates to the SRP server with the conflicting
> data, that SRP server will remove the old data and replace it with the new,
> which eliminates the conflict.
>
> I think this is pretty tight; the only problem is that it does rely on SRP
> replication working well. If SRP replication gets wedged, then the conflict
> won't be resolved until the old data expires. This is not great, of course.
>
I agree that SRP replication is an elegant solution in concept. I'd like to
get some implementation/operational experience on how well it works in
practice.

> An additional mitigation strategy is to not actually detect conflicts. If
> we have two conflicting registrations, and SRP replication doesn't resolve
> them, then they just coexist until one goes away. This should happen when
> the old SRP lease expires. This means that the consumer of the data has to
> be smart about it: if there are conflicting TXT records, it needs to have a
> strategy for choosing which one to trust. If there are conflicting address
> records, it needs to do happy eyeballs.
>
If there's no good way to invalidate the old entry, then I think presenting
both is the next best solution - it at least makes it possible to continue
communicating with the service. Although, as you noted, it requires extra
work by the consumer of the service data.

> The only other alternative is to rename. I think this is too heavy of a
> solution, but I'm open to debate. The problem is that if we rename, we now
> have two advertisements for the same accessory, so we're pretty much in the
> same place we'd be with the "don't detect conflicts" strategy, except that
> we have a gratuitous extra name.
>
> So consumers of the data now have to use some other identifier than the
> name to uniquely identify the device, and if there are two advertisements
> under two different names that present the same identifier, we now have to
> have a browse going to detect that, whereas if we don't change the name,
> dealing with an unresolved conflict is a lot simpler.
>
I agree. I don't see much value in renaming to address these self-conflict
scenarios.

--
Jonathan Hui