On Wed, 20 Sep 2006, Paul Francis wrote: > > 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
I mean, "did you perform TCP testing?" Your analysis of "affinity" is very limited. You state incorrectly that "none of the aforementioned studies have attempted to delve into reasons behind routing flaps". Which the qualification of "routing flaps", makes the statement literally correct, it is actually misleading. Several people including myself have offered analysis and references to sources of fine grained load balancing, both intentional, and unintentional, both at the client and within the network. Your data indicates that 92% of the "flaps" occurred with %1 of the clients. This suggests that perhaps something may be wrong with selection of clients. You don't explain this, and you don't report the number of times per day the %1 most affected, experienced "flaps". (I calculate 270 times per day for 17 days). One might wonder whether these 58 are actually experiencing a problem or simply have fine-grained load-balancing. I note also that you state that "anecdotal evidence from the anycasted J root-server" is also a mischaracterization of the reference. Kosters et al reported statistics they collected that showed that 3.6% of IP addresses showed up at multiple anycast servers. This isn't "anecdotal", so your characterization of that evidence is misleading. The data from J-root indicating 3.6% hosts at multiple anycast sites compares with your %1 or 58 hosts that apppear at multiple anycast sites. Your statement that "99% of the clients observe less than 10 flaps per day" is perhaps literally correct, but misleading: it obscures the fact that 92% of your flaps appear to be more than can be explained by network failure, as your perjorative and misleading use of the term "flap" implies. This spike in "flap" data should be the focus of any analysis of stateful anycast. Instead, your paper just dismisses this and misleadingly claims that there is "good" affinity. A reasonable person would not conclude that 58 hosts would continuously flap on average 270 times a day for 17 days without correction. There is no reason to think there is anything wrong with these 58 hosts. There is also no reason to think that if your set of clients were larger, that your data wouldn't converge to something closer to Verisign's statistics. Yet, your paper, rather misleadingly, seems to indicate otherwise. BTW, Root DNS servers aren't operated for 99% of the people. They are operated for 100% of the people who comply with RFC1812 and the DNS RFCs. Fine grained load balancing is a proper behavior under RFC1812. Your data, honestly interpreted, actually supports Verisign's data. Yet, misleadingly, you claim the opposite. > -----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/
