On Tue, Apr 21, 2009 at 1:57 AM, Tony Li <[email protected]> wrote: >>> 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. > > Well, the problem with aggregating anycast is that it ends up with one route > per service. In a world of highly differentiated services, the sheer number > of services could be explosive. And you can only aggregate them if they are > numbered appropriately and are topologically correlated.
How's that different from, say, cnn.com, aggregated with the other Turner services and spread across two of Turner's three unicast routes? If TCP was stable over anycast, they might actually be able to drop one of those unicast routes. Seems to me that the aggregability of services has more to do with the size of the services set than it does with whether the service is unicast or anycast. Big important web site = at least one more route in the table. > As for the forwarding plane, the differences are NOT that large. Ok, yes, > there is an order of magnitude more complexity in doing the packet > replication, but it becomes quite clear that with one receiver it does > devolve nicely into an effective unicast. Effective unicast that is an order of magnitude more expensive to implement. Anycast, on the other hand, is precisely the same as unicast in both the forwarding and data planes... And as I mentioned, it's relatively trivial to get it to look precisely the same in each of the two major solution strategies as well. > Even if multicast's differentiation is the replication in the data plane, > I'm not sure I see how that becomes non-deterministic. I see no references > to an oracle. The right things always seems to happen with total > determinism. I think of deterministic as "pick one direction" while non-deterministic is "travel all valid directions." I'm open to a better word choice. >> 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. > > Seems like useful implementation strategies to me. And it leads me again to > the conclusion that it's again not something that's happening within the > routing subsystem. I had a discussion with a colleague earlier today. He was having a problem with a mapping app on his web site going through a particular proxy server that didn't support http keepalive. To render a map page with all the plotted points, he would generate around 500 ssl http requests. With keepalive this would generate around 30 ssl connections. Without keepalive it generates 500 and runs so very much slower. Where's the error here? The proxy that doesn't support keepalive? Or the app that needs to generate 500 https queries in order to render a web page? Which one do you zero in on and change? The upper layers set requirements on the routing layer in a manner the routing layer can't handle efficiently. One answer is that we redesign the routing layer. Another is that we alter the requirements. Ruling either answer out of scope would, at the very best, be failing to think outside the box. On Tue, Apr 21, 2009 at 4:00 AM, <[email protected]> wrote: > As I understand Anycast is about delivery to one out of multiple > destinations within a given scope. Hi Heiner, I would have said "closest one from the set of valid destinations," but your version is good enough. > Where is the center point of this scope ? Is it always the location of the > source ? I don't understand the question. What is a center point wrt routing? > What are the requirements for Anycast in a new architecture? Well, that's the crux of the discussion, isn't it? Anycast and unicast are identical in every respect in the current architecture. How do we bound the unforeseeable consequences if that isn't true in the new one? I'm getting ready to introduce an anycast route into the table in order to implement a "continuing operations" system with three sites half a world apart. "Continuing operations" is a fancy phrase for "disaster recovery," something that became really popular almost 8 years ago. Once a packet hits any of the always-running sites, a VPN takes it back to the site with the servers flagged "best" for that particular address, so holistically its unicast but from the perspective of the Internet core its anycast from three distinct locations. Would this have any hope of working right in an architecture that didn't accommodate anycast? How many such uses are out there, ready to impede the deployment of the unwary plan? Regards, Bill Herrin -- 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
