Subject: RE: grow: WGLC for Operation of Anycast Services (draft-ietf-grow-anycast-04.txt) (fwd)

From: "Paul Francis" <[email-masked]>
Date: Fri, 22 Sep 2006 13:52:25 -0400

I'm afraid that the opportunity to change section 7 has passed...camera-ready
was due a couple weeks ago.

Looking forward to your collection of prior discussion.

PF

-----Original Message-----
From: Dean Anderson [mailto:[email-masked]] 
Sent: Friday, September 22, 2006 1:02 PM
To: Paul Francis
Cc: Hitesh Ballani; [email-masked]
Subject: RE: grow: WGLC for Operation of Anycast Services
(draft-ietf-grow-anycast-04.txt) (fwd)

Are you planning to remove section 7 before the IMC '06 conference?
Renaming the section and significant rewriting of that section seems a
possible alternative, as well.  Please let me know your intentions regarding
the stateful Anycast claims.

I am collecting a list of prior discussion and analysis relevant to your
paper. I will send you that by Monday.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

---------- Forwarded message ----------
Date: Wed, 20 Sep 2006 13:14:00 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Paul Francis <[email-masked]>
Cc: Hitesh Ballani <[email-masked]>, [email-masked], [email-masked],
     [email-masked], [email-masked]
Subject: RE: grow: WGLC for Operation of Anycast Services 
    (draft-ietf-grow-anycast-04.txt)

On Wed, 20 Sep 2006, Paul Francis wrote:

> We tested with a series of packets.  It was not TCP per se.  I don't 
> think it has to be TCP per se to test affinity.

An indirect answer.  Was it perhaps stateless UDP?  I agree that there are
other stateful protocols, but none seem to fit your methodology.

Your use of the word "affinity" is itself a misleading. It suggests a hidden
mechanism that doesn't actually exist.  The client has no control of Anycast
server selection. The Anycast server has no control over client selection.
Every router inbetween client and server, is capable of an independent route
selection.  There is no "affinity", as the word is defined and people would
interpret the word.  Instead, you have only performed a test of roughly
whether load balancing or some other mechanism such route changes (both
intentional and otherwise), exists in the path or not. The only thing your
data reveals is whether a client can see multiple anycast servers, and
roughly how often. This does not imply "affinity". Collecting statistics on
the number of clients that are serviced with load balancing or some other
fast switching mechanism, even if the number were zero, would not demonstrate
"affinity" between client and server.  Your result of "affinity" does not
follow from your testing.

What you've done is rather like asserting an affinity to processor 0 using
data from a lot of uniprocessor machines, and a few multiproccessors, when
there is no affinity mechanism in the operating system, as evidenced in the
large degree of random behavior of the small number of multiprocessors.  I
think most people would find that to be an misleading result.

And given that you are aware of load balancing as a cause of stateful Anycast
problems, it seems misleading to describe DNS TXT queries as "route flap"
indicators. The existance of a "route flap" is a conclusion that has to be
infered from other facts besides the change of Anycast server.

> Where did you publish your analysis?   

Discussions on DNSOP and DNSEXT Working Groups 2002-present, Nanog, and the
main IETF list. These are proceedings of a professional society, from which
ideas were apparently taken, but not properly credited.

		--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/

_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: "Paul Francis" <[email-masked]>
Date: Sat, 23 Sep 2006 20:52:46 -0400

BTW, I'm in no way convinced that our paper is wrong, so of course won't
retract the paper.  I was wondering if your results would change my
conviction, but until I see your results of course I can't change my mind.

Actually, this should be something of an opportunity for you.  You can
publish your results in IMC or some other conference next year and overturn
previous results (indeed, you'd be overturning the best paper award paper!)
which would create quite a buzz.

PF

-----Original Message-----
From: Dean Anderson [mailto:[email-masked]] 
Sent: Saturday, September 23, 2006 4:00 PM
To: Paul Francis
Cc: Hitesh Ballani; [email-masked]
Subject: RE: grow: WGLC for Operation of Anycast Services

On Fri, 22 Sep 2006, Paul Francis wrote:

> 
> I'm afraid that the opportunity to change section 7 has 
> passed...camera-ready was due a couple weeks ago.

That is unfortunate. It seems you have a problem, then.  I hope that you are
able to retract the paper before it is published.  Otherwise, you will be
publishing a false result which, especially in the circumstances of
controversy of which you were previously aware, cannot be excused.

> Looking forward to your collection of prior discussion.

And so there also seems to be no rush to get this collection to you, since it
is too late to make corrections for IMC '06.

		--Dean

> possible alternative, as well.  Please let me know your intentions 
> regarding the stateful Anycast claims.
> 
> I am collecting a list of prior discussion and analysis relevant to 
> your paper. I will send you that by Monday.
> 
> 		--Dean
> 
>