I'm afraid that the opportunity to change section 7 has passed...camera-ready was due a couple weeks ago.
Looking forward to your collection of prior discussion. PF -----Original Message----- From: Dean Anderson [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 1:02 PM To: Paul Francis Cc: Hitesh Ballani; [EMAIL PROTECTED] Subject: RE: grow: WGLC for Operation of Anycast Services (draft-ietf-grow-anycast-04.txt) (fwd) Are you planning to remove section 7 before the IMC '06 conference? Renaming the section and significant rewriting of that section seems a possible alternative, as well. Please let me know your intentions regarding the stateful Anycast claims. I am collecting a list of prior discussion and analysis relevant to your paper. I will send you that by Monday. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ---------- Forwarded message ---------- Date: Wed, 20 Sep 2006 13:14:00 -0400 (EDT) From: Dean Anderson <[EMAIL PROTECTED]> To: Paul Francis <[EMAIL PROTECTED]> Cc: Hitesh Ballani <[EMAIL PROTECTED]>, [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/ _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/
