On Wed, 12 Jul 2006, Joe Abley wrote: > > On 12-Jul-2006, at 15:45, Dean Anderson wrote: > > >> I make no claims that anycast is definitively safe for protocols and > >> services which don't involve trivial, stateless transactions. > > > > Really? That's a big change. > > Really? There has been text to that effect in the draft since -00. Searching draft 4 just now, I can find no instances of the words "safe", "trivial", or "stateless" in the draft. So, I suppose, quite literally, it is true that you didn't make such a claim in the __draft__. But you and your group did make these assurances elsewhere. This is sort of legalistically dishonest: Rather like an unscrupulous used car dealer claiming he never promised the car would start in the sales contract, even though he did say so on the lot. I did notice a number of "bait and switch" between draft 02 and 03 (which I noted to you and the IESG). In those cases, you quietly weakened the statements made. For example: =============================================================== Date: Thu, 29 Jun 2006 13:50:42 -0400 (EDT) From: Dean Anderson <dean@xxxxxxx> To: Joe Abley <jabley@xxxxxxxxxxxxxxx> Cc: Sam Hartman <hartmans-ietf@xxxxxxx>, iesg@xxxxxxxx Subject: Re: grow: draft-ietf-grow-anycast-pre04 [...] On the issue of "minor changes": This is a major change: - discrete locations. The service provided by each node is consistent - regardless of the particular node chosen by the routing system to - handle a particular request. + discrete locations. The service provided by each node is generally + consistent regardless of the particular node chosen by the routing + system to handle a particular request (although some services may + benefit from deliberate differences in the behaviours of individual + nodes, in order to facilitate locality-specific behaviour; see + Section 4.6). The change from "is consistent" to "is generally consistent" is a significant difference. To be a safe stateful operation, "is consistent" is required behavior. You assured people that it is safe, and then you "bait and switched" the text to weaken the official statements in spite of your stronger assurances. This is a nefarious change. [...] =============================================================== > >> For example, there are people using anycast to distribute services > >> using very long-held sessions (e.g. internet radio, HTTP) with > >> great success, and to ignore their experience and success would be > >> idiotic and arbitrary. > > > > There are no such http services using stateful anycast (though this > > is the first I've heard of internet radio being anycast---I'd have > > to question what protocol he means. I think RTP streams may be > > stateless, but I'm not certain). The http protocol is definitely > > stateful, however. > > http://www.computerworld.co.nz/news.nsf/NL/54FCC3B9D0B8BB96CC25702F00740446 This link is a June 30, 2005 announcement from Radio New Zealand. It makes no mention of the protocol they plan to use. It does make mention of anycast root DNS servers, as though that adds credibility to their scheme. There is no data that this scheme is stateful nor, if it is actually stateful, that it is safe. Nor this announcement mean they are having any success with this scheme over a period of time. I don't know if they are still using this scheme, nor if they even implemented the intentions announced June 30, 2005. This is a rather weak reference. > http://www.nanog.org/mtg-0606/levine.html First, check the date: June, 2006. Not very long time to check their data, and __after__ you efforts began. You've been promoting this scheme since 2002, saying it was stable then, with years of commercial use. Second, you seem to miss a lot: (page 5) "State is accomplished with custom hardware." As much as they bluster about doing "TCP anycast", it is not actually TCP Anycast. They have some special hardware doing state behind the scenes. They don't give many details, though. But that is different from what we are discussing. You've proposed no custom hardware. You and they are essentially doing something that akin to confusing the Mount Everest ride at Disneyland to climbing Mount Everest, because they gave you a "I conquered Mount Everest" sticker. Third, they are doing Porn video streaming, so customers probably don't complain too much about frequent failures. Fourth, it is my understanding that Real Media and MS Media player streams are RTP, not TCP. They are not real clear on those points. Fifth, their performance data indicated that over a long period of time, they never had 100% availability. This is from only 31 locations. Their data shows that some connections always failed. They never reached 100% availability. That would be "unsafe". Sixth, Cache networks was established in 2002: "CacheNetworks, established in Berkeley, CA in 2002, provides fast, affordable content delivery through a superior distribution network with points of presence located throughout the United States. When a visitor attempts to access content, they are sent to the location that will yield the quickest access times. CacheNetworks allows companies to rapidly expand and adapt their websites, seamlessly and without additional infrastructure, all backed up by 100% availability guaranteed SLA (Service Level Agreement)." Established in 2002: No very long term use of stateful anycast there. Certainly not the 9 or 10 years asserted by Vixie and Bush. I also notice that the data they posted to Nanog indicates that they never, ever, achieve 100% availability, in spite of their SLA guarantee mentioned in the press release. > etc, etc. I think I've said enough in this thread, now; if there are > innocent bystanders who would like more clarification of these issues > they are more than welcome to drop me a note directly. You haven't given __any__ examples of http use, or anything definitely stateful, even. Or anything that even predates your beginning this scheme in 2002. The examples you did give didn't really support your point. They appear to be people who have "drunk your koolaid"; they are taking direction from your group, and hoping it will turn out OK. But of course, they aren't looking for particularly good results. And where they published numbers, they don't seem to be getting good results. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf