Is this why digital archery is borked?

Kevin Murphy, June 24, 2012, 06:36:45 (UTC), Domain Tech

Another possible explanation has been put forward for ICANN’s suspension of digital archery, this time by one of the third-party digital archery service providers.

The ambitiously named Digital Archery Experts says it alerted ICANN to the presence of a technical problem a week ago.

Chief technology officer Dirk Bhagat described it thus:

Instead of generating the timestamp immediately, we believe the TAS timestamp generation process may be delayed by increases in system load…

Since most applicants are aiming for the 000 millisecond variance at the minute mark, this can introduce varying timestamps since applicants are shooting for the exact same second on the minute. We have also noted that our results were a lot more consistent when attempts were made to hit the target at various offsets after the minute mark, for example, aiming for 15:32:07 instead of 15:32:00.

It’s not exactly rocket science. In short, he’s saying that the TAS can’t handle too many applicants logging in and shooting at the same time; more load equals poorer performance.

This won’t be news to many applicants, some of whom saw downtime last week that seemed to be caused by a meltdown of the sluggish Citrix virtual machine software.

It also seems to be consistent with the hypothesis that the massive amount of calibration going on — much of it by digital archery service providers themselves — has caused more load than TAS can handle.

With only 20% of applications currently assigned a timestamp, and only a week left on the clock, the situation could only have been exacerbated by lots of last-minute arrows being fired.

While digital archery may be conceptually similar to grabbing a dropping domain or hitting a landrush, it seems pretty clear that TAS is not as redundantly provisioned as the typical registry SRS.

Bhagat said that ICANN could mitigate the impact of the problem by separating timestamp generation as much as possible from the parts of the infrastructure impacted most by system load.

This might all be academic, however.

ICANN suspended digital archery yesterday, a day after new gTLD program director Michael Salazar quit for reasons unknown.

Digital archery and batching are high on the agenda here at ICANN 44 in Prague, and many attendees hope that the controversial system may be gone for good before the week is out.

That includes some members of the Governmental Advisory Committee, which in an open meeting yesterday seemed to be coming to the conclusion that it would advise ICANN to ditch digital archery.

The GAC and the ICANN’s board’s new gTLD program committee are having their first public facetime this afternoon at 1630 local time, at which a better sense of how both plan to proceed might emerge.

Tagged: , , , , ,

Comments (3)

  1. KD says:

    Its sad. Why do you need a Citrix system to handle digital archery? I guarantee I can do it all on one single quad core Xeon processor. If ICANN is overseeing the technical nature of the Internet, how can they keep failing at the most basic of tasks. Did nobody load test these systems?

    • Rubens Kuhl says:

      The main idea behind the Citrix system appears to be preventing application vulnerabilities to be exploited. The TAS system is not exposed to the net, but rather accessible only from the Citrix environment where the users only have standard Internet Explorer to play with.

      I wouldn’t built a solution like this, but I can understand the idea.

  2. Derek says:

    I don’t see how or why using this Citrix system is in any way more secure than any other sort of proxy setup. It is a ridiculous amount of overhead:

    Basically you have what amounts to a “remote desktop” from your client machine, running a browser plugin that uses the same protocol used by GoToMeeting, which basically tunnels a VPN connection through https to a farm of virtual machines running Windows. The TAS “application” itself appears to be no more than a website being accessed via Internet Explorer. No details are available about what is running on the back-end, but it wouldn’t surprise me to find out that it is an .aspx script running under IIS, making connections to an Oracle database.

    So when you click “Generate”, the plugin receives the mouse-click, visually depresses the “Generate” button, uses the ica protocol to communicate the “click” through the SSL vpn tunnel to a XenApp server, which results in a “click” on the “real” Generate button in the IE browser window running on the XenApp server, which in turn does an HTTP POST to some back-end server, executes an .aspx script, which inserts a record into an Oracle database on a separate Oracle server, which uses a timestamp field to record the exact time of inserting the row. (Likely because Windows is unable to provide a precise timestamp without special programming).

    What ICANN should have done instead was set up a regular farm of webservers running Linux (without any Citrix/Xen/VM stuff), use a load-balancer with a “sticky” setting to make sure that for the duration of your “session” you are consistent sent to the same physical webserver, and have the very first thing that the resulting script does before anything else, is to accurately grab the webserver’s current timestamp (using gettimeofday), which can then be inserted into a database.

Add Your Comment