On Tue, 19 Sep 2006, Hitesh Ballani wrote:
> Dean,
>
> > Hitesh, do you have any data to backup your assertions about stateful
> > anycast?
> The data collected by us as part of our IP anycast measurement study is
> publicly available at http://pias.gforge.cis.cornell.edu/measure.php
> (the "Affinity Data-set"). An explanation of how this data was
> collected, the analysis and its implications are discussed in Section 7
> of our measurement paper
> http://pias.gforge.cis.cornell.edu/pub/anymeasure-imc-camera-final.pdf .
> Please take a look.
I'm looking now.
> I'd be more than happy to help out in case you want
> more details about the analysis. And I hope you read the part in my
> earlier mail about a small fraction of clients which see poor affinity
> (seemingly due to load-balancing at or close to the client-site) and
> hence, the need for "caveats" when talking about stateful anycast.
Yes, I originated the analysis of load-balancing as a factor of
instability in stateful Anycast. Since fine-grained load balancing is a
feature of RFC1812, it can't be defined away.
It is the lack of discussion "caveats" is what makes the
ietf-grow-anycast-draft misleading.
I also notice that much of your analysis follows mine, yet I am not
cited. Why is that?
I notice that you do not cite the Karrenberg paper in your (to be
published?) October 2006 paper. Is this an oversight, or it is because
of the fraudulence?
Also BTW, I notice that you appear to have been misled by the draft: If
anycast works for reliably any stateful protocol, it works reliably for
_all_ stateful protocols. If this were true, there would be no need to
consider the details of the specific protocols, anymore than say,
Gigabit Ethernet needs to be tested with specific protocol. On the
other hand, if anycast can't reliably keep state, it doesn't work
reliably for any stateful protocol. Suppose one created BrokenBit
Ethernet, where 3% of the packets were delivered to the wrong host. It
wouldn't work reliably for any stateful protocol. This is fundamental:
If anycast reliably keeps state, it can be used to reliably implement a
finite automaton or a turing machine. If it doesn't reliably keep
state, it cannot reliably implement either a finite automaton or a
turing machine.
Many years ago, while working for Kendall Square Research, a company
than built supercomputers, the hardware team was working on a bug that
happened only every once in a while. I coined a joke about the
statistical supercomputer, that statistically gave the right answer if
you repeated the calculation enough times. While the joke was obviously
never told to customers---and the hardware group only laughed nervously
---I have no doubt that customers would have been very unhappy if it
weren't found and fixed. No one wants a computer that works 96% of the
time. That's a pretty significant "caveat" to forget to mention. Most
people, I think, would consider such an omission misleading.
So, I'd ask you again, is the draft misleading?
--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/
