On Mon, Apr 20, 2009 at 1:02 AM, Tony Li <[email protected]> wrote: >> I disagree with you there. Broadcast and Multicast are forms of >> non-determinisitic routing. Anycast and unicast are both forms of >> deterministic routing. > > Interesting. That rumbling sound you here is Dino's keyboard... ;-) How do > you figure it's non-deterministic? If you take a global snapshot at any > given point in time, then for any given mcast packet sent by a given source, > it's straightforward to compute the receivers.
Hi Tony, I have this mental picture of the NFAs and DFAs (finite automata) used to process regular grammars from the formal languages class I took in college. All NFA's can be translated to DFAs but the translation explosively grows the automata. Seems to me like NFAs are decent metaphors for broadcast and multicast while DFAs are metaphors for anycast and unicast. And I think its notable that anycast groups with unicast (it's DFA-like) instead of grouping with multicast. > Except that we haven't figured out how to aggregate anycast, which from a > routing perspective, makes it completely unique. What do you mean? Anycast aggregates the same way as unicast: whenever the endpoints physically group together, they aggregate. At a practical level, that's rarely useful for anycast... But then at a practical level aggregating unicast that way (or failing to) is the source of our current grief. >> The same can't be said of multicast. Multicast has different semantics >> even if there's only one host in the group. > > Say more please, I'm not following. With anycast, the packet's next hop is always in exactly one direction, precisely the same as with unicast. And knowledge about what that next hop should be propagates precisely the same way. With multicast, the packet is replicated in all currently valid directions with complex subscription/desubscription overhead that has to be maintained even if there's only one receiver in the group. >> If using DNS that way worked, we could all go home. Unfortunately, >> what happens is that the ntp server looks up the name to address >> binding once when the machine boots and never reconsiders it during >> the year and a half the server is running, even after queries to the >> server's IP address stop returning data. > > Ok, but how would a map resolution change that? Is the key point here that > whatever mapping function is used, the map result has a TTL and needs to be > refreshed periodically? Or, the applications need to be able to trigger a > refresh? You'd put the map resolution outside the app developer's scope, either in the network (as proposed by strategy A) or in the system-level host software (as proposed by strategy B). Unprivileged applications simply wouldn't be able to diddle with addresses at the routing layer. With a guaranteed maximum time that a given map remains valid and no application-level access to the routing element, the protocol and weigh in favor of renumbering for aggregation instead of rerouting for multiple connections. But this is rather off on a tangent from anycast and its rather identical nature to unicast. On Mon, Apr 20, 2009 at 4:38 PM, Scott Brim <[email protected]> wrote: >> When I say, "Unicast is a case of anycast in which there is only one >> destination endpoint," I really mean it. Unicast doesn't exist. It's >> just a convenience label for Anycast in which only one destination >> endpoint is currently active, and that's precisely how the routing >> system treats it. >> >> The same can't be said of multicast. Multicast has different semantics >> even if there's only one host in the group. > > How would you change the definition of a locator to match this? Hi Scott, Outside the context of specific solution strategies, I'm not sure the term "locator" is useful here, in any of its definitions. The most helpful term I've found here that could use a definition is "respondent," the particular anycasted device that you end up talking to. On Mon, Apr 20, 2009 at 12:51 AM, Robin Whittle <[email protected]> wrote: >> You do a map lookup on the destination. You get a prioritized list >> of of egress routers. > Ivip's mapping has no list. Hi Robin, Call that a criticism of Ivip then. The change from current routing's presentation to the app layer will have consequences, some foreseeable and others unexpected. >> Stable TCP over anycast would, by the way, be fantastic news for the >> CDNs and their customers which include, oh, just about every major >> content provider on the web. > > I can't imagine any robust approach to TCP using anycast. The > routing system could change at any time and direct the packets to > another destination host. The routing system can change any time, interrupting communication between two endpoints. From a CDN's perspective, it just has to remain stable long enough to deliver the content about as often as it succeeds without anycast. The real problem with making TCP stable over anycast is not not routing changes that connect you to a different respondent. It's that you can be equidistant between two respondents with routing configured to send packets to one or the other more or less at random. If you rigged the routing system so that given two equidistant routes you picked one and then stuck with it until either the one you selected was withdrawn or until the metric on the other improved by at least two or three distance units, you'd have TCP over anycast that's stable enough for a substantial number of use cases. Certainly stable enough for a case like adding and removing machines from a geographically distributed web cluster. Regards, Bill -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
