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(_at_)av8(_dot_)com>
To: Joe Abley <jabley(_at_)ca(_dot_)afilias(_dot_)info>
Cc: Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu>, iesg(_at_)ietf(_dot_)org
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf