On 24-07-2004 23:10, "Marc Krochmal" <email@hidden> wrote:
>> * Section 10, second paragraph: " Whenever a Multicast DNS Responder
>> receives any Multicast DNS response (gratuitous or otherwise)
>> containing a conflicting resource record [...]". It is not entirely
>> clear what exactly the trigger is. I can imagine four triggers:
>> [...]
>> Third, a *request* with a record in the authority section, as
>> described in section 9.2, with different rdate which the *observer*
>> beliefs it should be unique.
>
> That request would not be considered a conflict, since the request is
> actually a probe that will cause the real owner of that name to
> respond. That would not be a trigger for the real owner of that record
> to reset to probing state.
It's clear to me now. I somehow mistakenly imagined that the original owner
would also go into probe state after a probe from another host, and that it
then negotiate who gets to own the record in the new situation (as opposed
to the first comes first serves bases). Don't know why I thought so. If I
find the text that accidentilly put me on the wrong foot, I'll let you know.
This does mean however, that the following issue will become more important,
since probing may give a different end-result then conflict resolution
(probing: first comes-first serves; conflict resolution: whoever is
lexicographically latter):
[Comment about probing, Section 9.1, page 18, slightly rewritten]
> Second, this behaviour is not ideal in the following situation: at
> t=0, mDNS responder B sents a response with record x, for whatever
> reason. At t=0.1, mDNS responder A wakes, waits (let say 0.05s),
> [probes for] record x, with different proposed rdata. B detects the
> conflict shortly after, but is not allowed to respond until t=1,
> according to the last line of section 8.0. However, at
> t=0.1+0.05+3*0.25 = 0.9, A already decided that there is no conflict,
> and announces record y. Perhaps, the restriction in section 8
> should be loosened in case of conflicts, or in the case of probes
> (e.g. when a request contains an authority sections)
Marc, you wrote:
> Actually, it's assumed that queries will be answered within 120ms,
> although we plan on adding some new text to the spec that says, if the
> TC bit is set on the query, then the responder SHOULD wait between
> 400-500ms before responding so it has enough time to receive all the
> Known Answer packets on a busy 802.11b network. We learned this from
> operational experience.
120ms might be too short!
For one thing, this surely conflicts with the 1 response/second requirement.
In practice, I fully admit that for home networks, this is long enough
(except indeed for busy 802.11b networks). However, I do see a clear
tendency in networking to move away from routers to switches, particullary
in MAN networks. The reason is simply cost (a 32 port 10 Gb/s routers cost
~10 mln $, a 32 port 10 Gb/s switch maybe ~1 mln $). Thus, it is likely that
what you would call 'link local' extends from 5 ms to 50 ms scale. Examples
of state-wide networks wihtout routers exists. For example I-Wire in
Illinois. I have no clue if something like Zeroconf will ever be used on
those networks (currently not, but I can't predict the future), but it might
me good to consider. I seriously consider zeroconf-ipv4-linklocal for
'lambda networking' (making a dedicated end-to-end connection between
end-hosts up to 300 ms apart). At least draft-ietf-zeroconf-ipv4-linklocal
takes 1 second as the max. response time, and I think multicast DNS should
do so as well. That said, I think the text does support that. I've only seen
the 120 ms mentioned as a time that a request may be delayed in order to
avoid collisions.
Regards,
Freek Dijkstra
_______________________________________________
rendezvous mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/rendezvous
Do not post admin requests to the list. They will be ignored.
