[dnssd] Some feedback on draft-tllq-tsr-00 (A 'Time Since Registration' Resource Record for Multicast DNS)

[Liang qin <[e-mail]>]

I have some feedback on draft-tllq-tsr-00
<https://datatracker.ietf.org/doc/draft-tllq-tsr/> (A 'Time Since
Registration' Resource Record for Multicast DNS).

I'm working on implementing and unit testing the proposal in this draft, it
works well and fulfills the purpose of this record, it also fits well into
the existing multicast DNS and DNSSD framework.

I have two interesting observations though:

1.The TSR record will conflict with itself and sometimes lose to itself;
Since probe is multicast, prober will receive probe packet from itself and
compare the tsr value with itself, most of the time these two values are
equal, but in some corner case, it will lose to itself, for example:
In our TSR record, tsr value is 1636142582;
In packet record, tsr value is 0(notice that the tsr value in packet is
relative time) which means now;
Then when we get the absolute tsr value for the packet, it can become
1636142583, it may be because the original timestamp is generated very
close to 1636142583 and there is some delay when transmitting the packet.
In this case if we compare the tsr value in our record with the tsr value
in packet sent by ourselves, we will lose.
We probably want to add a `MinTSRInterval` value to make sure prober needs
to be at least `MinTSRInterval` seconds more recent to win in conflict, for
example `MinTSRInterval` can be set to 10 seconds.

2.TSR does not work with auto rename in some implementations;
In some implementations, when auto rename happens, only the name of the
service is changed, other data structures are reused including the TSR
record attached to the name.
This will cause the losing side in conflict to keep renaming because it's
tsr value is not changed.

Since TSR is not designed to work with auto rename, it's the client's
responsibility to make sure auto rename is disabled when the TSR record is
used.

Thanks
-Liang