Multipurpose Transaction Protocol: A New Data Transport Model

When engineers at the Advanced Computing Engineering (ACE) group began testing MTP/IP ExpeDat, they saw their transfer times jump from around 6 megabits per second to over 42 megabits per second. Transfers that had been taking 90 minutes were now done in just 12. They had always known their WAN had a theoretical capacity of 45 megabits per second, but had been unable to achieve it using TCP based technology. ACE engineers immediately saw the potential; simulation jobs could be load balanced on a global scale. Managers saw the potential to increase service levels with the same or even fewer clusters.

Initial deployment required two components: distributing the server software to the clusters, and the client software to the engineers. But first they had to get corporate IT to sign off on a new (and, back then, unknown) technology. MTP/IP borrows the UDP/IP packet format, so it works on any standard IP network. But network managers wanted to be sure that the performance gains were not coming at the expense of other users. Several weeks of testing proved there were no disruptions. Even so, managers only really hit their comfort zone when they realized that MTP/IP has builtin bandwidth controls so they could be explicit about things like maximum bit-rate and latency.

Server deployment ran into only one hitch — firewalls. Like any new application, a port had to be opened. But this had to be done on all the firewalls and it has to be the right port. Early on, there were frequent mix-ups between TCP ports and UDP ports (they are different) and administrators who didn’t realize how many firewalls they actually had. Improvements to the software documentation, and a new diagnostic tool that can trace the location of an offending firewall, were needed to remove those issues.

Client deployment was surprisingly smooth. Since the end-users were already familiar with the FTP and SCP interfaces upon which ExpeDat had been modeled, they adapted readily to the new software. The biggest problem early on was keeping up with the flood of requests for new features.