Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mDNS draft comments

On Jul 25, 2004, at 4:24 AM, Freek Dijkstra wrote:

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)

Yes, this is a good point. Either we remove the restriction for probes, or we could increase the interval between probes from 250ms to 500ms.



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.

Yes, 120ms is the delay before responding to avoid collisions. The fact that the protocol uses multicast implies that there will be some amount of packet lost expected, which is why queryers should be prepared to re-issue their queries (with exponential back-off). It's expected that most queries will be responded to within 20ms - 500ms, however, because of packet loss and because of the 1 response/second requirement, a very small number of queries will go unanswered, and so queryers should be prepared to re-issue queries.

Best Regards,

-Marc
_______________________________________________
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.

References: 
 >Re: mDNS draft comments (From: Freek Dijkstra <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.