My mistake...I didn't actually follow the discussions on all of those mailing lists.
Would it be possible for you to summarize your contributions to those discussions? PF -----Original Message----- From: Dean Anderson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 1:14 PM To: Paul Francis Cc: Hitesh Ballani; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] Subject: RE: grow: WGLC for Operation of Anycast Services (draft-ietf-grow-anycast-04.txt) On Wed, 20 Sep 2006, Paul Francis wrote: > We tested with a series of packets. It was not TCP per se. I don't > think it has to be TCP per se to test affinity. An indirect answer. Was it perhaps stateless UDP? I agree that there are other stateful protocols, but none seem to fit your methodology. Your use of the word "affinity" is itself a misleading. It suggests a hidden mechanism that doesn't actually exist. The client has no control of Anycast server selection. The Anycast server has no control over client selection. Every router inbetween client and server, is capable of an independent route selection. There is no "affinity", as the word is defined and people would interpret the word. Instead, you have only performed a test of roughly whether load balancing or some other mechanism such route changes (both intentional and otherwise), exists in the path or not. The only thing your data reveals is whether a client can see multiple anycast servers, and roughly how often. This does not imply "affinity". Collecting statistics on the number of clients that are serviced with load balancing or some other fast switching mechanism, even if the number were zero, would not demonstrate "affinity" between client and server. Your result of "affinity" does not follow from your testing. What you've done is rather like asserting an affinity to processor 0 using data from a lot of uniprocessor machines, and a few multiproccessors, when there is no affinity mechanism in the operating system, as evidenced in the large degree of random behavior of the small number of multiprocessors. I think most people would find that to be an misleading result. And given that you are aware of load balancing as a cause of stateful Anycast problems, it seems misleading to describe DNS TXT queries as "route flap" indicators. The existance of a "route flap" is a conclusion that has to be infered from other facts besides the change of Anycast server. > Where did you publish your analysis? Discussions on DNSOP and DNSEXT Working Groups 2002-present, Nanog, and the main IETF list. These are proceedings of a professional society, from which ideas were apparently taken, but not properly credited. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/
