Awww heck, I'm in a rascally mood... What do you mean by "stateful testing"? By which I mean we tested "affinity", which is the extent to which packets from the same host go to the same anycast server over a long period of time. From this we can make statements about how often TCP connections would break (due to a flap). I consider this to be stateful testing.
PF -----Original Message----- From: Dean Anderson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 7:21 AM To: Hitesh Ballani Cc: [EMAIL PROTECTED]; Paul Francis; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] Subject: Re: grow: WGLC for Operation of Anycast Services (draft-ietf-grow-anycast-04.txt) On Sun, 17 Sep 2006, Hitesh Ballani wrote: > Again, the use of IP Anycast for stateful services has probably been > passionately debated on this and other forums and many past studies > have presented a different picture of this. FWIW, we found that IP > Anycast does offer a very good substrate for most stateful services > (Section 7 of [1]). I have just read your paper, "A Measurement-based Deployment Proposal for IP Anycast" and the paper does not find that "IP Anycast does offer a very good substrate for most stateful services" in either the abstract or in Section 7. There seems to be no basis for this statement in the paper, except through mistake due to misleading discussion contained in the paper. The paper discusses some of the issues that are related to stateful anycast---Issues that are unrelated to stateLESS anycast, and so therefore one may be misled into assumptions about relevance to stateful Anycast. The discussion of those issues is incomplete and fragmentary. For example, in Section 7, you mention that a route "flap" could cause a TCP connection to break. This is true, but so can fine grained load balancing, which you omit. Elsewhere, you mention load balancing at the client, but omit discussion of load balancing at other points between the client and the anycast server. Load balancing at any point is equally deadly to stateful Anycast. Your paper does cite other papers which state that stateful Anycast (TCP) is a problem area, and you seem to be aware of the controversy involving stateful Anycast, but you omit any detailed analysis of stateful topic, and don't make any specific claims of stateful testing. This seems misleading, especially given your comment quoted above. Since you are aware of the controversy, there is no excuse for any lack of clarity or ambiguity regarding stateful and stateless anycast. Yet there is no clear statement regarding the relevancy of the findings of your paper on each subject. Your paper also cites other papers call for most testing as a motivation for your study. I note that there is no call for stateless studies, but rather for stateFUL testing. Something I'm starting to suspect, but isn't explicitly stated in the paper, is that your study is only relevant to stateless Anycast. Before I slog though your data, is any of your data stateful? Have you done any stateful testing? I believe that until your paper is adequately clarified, your paper should be withdrawn or withheld. -- 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/
