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

> On the other hand we see conflicts all the time with SRP because of the two-SRP-server mDNS conflict detection algorithm, so it's pretty clear that SRP + mDNS conflict detection is a recipe for creating conflicts.

Could you explain why there are so many conflicts because of
two-SRP-server mDNS conflict detection algorithm?

Are the SRP servers using SRP Anycast TLV or Unicast TLV?

I would expect name conflicts to happen more often if SRP servers are
using Anycast TLVs because a SRP client can change SRP server for each
registration or renewing.

When SRP servers are using Unicast TLV, a SRP client should stick to
the same SRP server for registration and renewing, even after the SRP
client is rebooted.
A SRP client may change SRP server when there are multiple request
failures, but I would expect it to be less often.
So, I would not expect many name conflicts for SRP servers using Unicast TLVs.

On Sat, Aug 14, 2021 at 6:40 AM Ted Lemon <mellon@fugue.com> wrote:
>
>
> On August 13, 2021 at 6:24:51 PM, Jonathan Hui (jonhui@google.com) wrote:
>>
>> Another thing to be aware of is that because of the way mDNS works, if you are using mDNS for discovery, a name conflict when names aren't being defended will sit around in the cache for a few minutes. If names are defended, this doesn't happen; one alternative is to just defend names and count on SRP to deal with conflicts, but the downside of this is that now there is a delay before the new information appears.
>>
>> This delay could potentially be minimized by retrying to register as soon as the SRP replication update has been acknowledged by all SRP replication peers—right now my code (when name defense is enabled) just waits two minutes before re-attempting, which is a lot longer than should be necessary.
>
> Sounds like a good idea to explore. My initial concern is that waiting for positive confirmation from all peers can lead to other failure modes resulting from poor implementation or connectivity. At the same time, those same assumptions are what would lead us back to needing other mitigations.
>
> The problem with anything that's ad-hoc and not integrated into the infrastructure is that there's no model that guarantees success. It's always going to be best effort. The goal has to be to make "best" as good as possible, but have a backup strategy for when it's not quite good enough.
>
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd