
FYI ----- Begin forwarded message ----- Date: Thu, 24 Mar 2005 17:13:04 -0500 From: Hitesh Ballani <hitesh@cs.cornell.edu> To: RIPE NCC RIS <ris-request@ripe.net> Subject: Re: NCC#2004081420 RIPE beacon request! Message-Id: <1111702384.25482.28.camel@devilman.u.cs.cornell.edu> Hello Arife,
I was thinking to contact you about the latest change in Beacons. I hope you noticed that. We were running out Beacon prefixes, and got new big block from RIPE, and replace the previous ones with new one.
Latest changes are here,
Yep, I noticed that .. thanks!
About your request, I have to discuss with my colleagues and get back to you.
Sure!
BTW, do you have any results online about your previous experiement? It would be nice to look at it. Lorenzo, a colleague of mine, is also doing somework about anycast root servers.
Its great to hear that other people are interested and working on anycast too. In the intervening weeks (months?) since we last talked, I have done a bunch of anycast measurements. Most of the earlier measurements were to support of our anycast architecture proposal (http://www.usenix.org/publications/library/proceedings/worlds04/tech/ballani...). Attached is our subsequent submission to SIGCOMM (please do not forward the paper outside your group) - section IV.A and IV.D describe those measurements. Beyond this, we realised that it would be good to do a detailed measurement study of current anycast deployments (i.e. DNS root-servers and AS-112 servers). This study was conducted over a period of 3 months. I summarize our main results here: 1. That anycast, as deployed today, is quite poor at selecting the closest server in terms of latency. We think we know why, and that it can be fixed, but nevertheless that is what we see. (Section IV.D of our SIGCOMM paper) 2. That anycast is quite good in preserving affinity - during the period of the study, I maintained a web-site which showed my latest results (http://www5.cs.cornell.edu/~hitesh/anycast-g2.html). This disagrees with data from a study done by the operators of J-root who argued against running connection oriented services on top of anycast based on their measurements. Hence the need to do a wider scale study and this is why i need your cooperation. We plan to describe these in a measurement paper and submit to IMC in May. It would be great to see what you guys are interested in and maybe I can help you out. -- Thanks, Hitesh p.s. the above description is highly condensed - feel free to ping me if you have any questions/comments.
Regards. Arife
On Thu, 10 Mar 2005 03:56:08 -0500, Hitesh Ballani wrote:
Hello Arife,
Thanks for your help with my last experiment - but I need an even bigger favor now. I am going to describe my requirements below - if you do not find them feasible, please feel free to tell me so. Also, if you have stopped leasing out beacons to external researchers, I totally understand.
I need a prefix to be advertised to many RRCs (as many as possible) for the duration of a week or so. However, this time I also need the RRCs to run a nameserver and answer queries for a particular domain. My friend here at Cornell owns a domain name (guha.cc) and hence, I can point anycast.guha.cc to the anycast address you assign to me. So for example, assume you assign a prefix a.b.c.0/24 to my experiment and it is advertised by 8 RRCs. I want all the 8 RRCs to run a nameserver and answer DNS queries (type A) for anycast.guha.cc - each RRC will answer with a different address. Hence, the first RRC will answer with a.b.c.1, the second with a.b.c.2 and so on. The purpose of this is that such an arrangement allows me to use thousands of DNS servers which have recursion enabled to perform my measurements and hence, adds a lot of value to my anycast study. The above mentioned approach for measurement is known as KING and was developed at U.Wash (described here http://www.cs.toronto.edu/~stefan/publications/imw/2002/imw.html).
In case this sounds vaguely feasible, I would be more than happy to give you more details or clarify any doubts you may have. We have used the King approach for anycast measurements against the anycasted root-servers - and so, have some sense of what is required. You might have security concerns regarding running a name-server on your RRCs. I think there are standard techniques (eg. running BIND in a chroot JAIL) by which we can ensure that this experiment does not add any vulnerabilities to the RRCs - again, I can provide with more information/help in case you are interested.
Thanks for your time, Hitesh
------ End forwarded message ------