Proprietary MTP: an alternative to TCP?

brianboyko.jpgBy Brian Boyko
If you spend some time poring through RFC documents (something I don’t recommend for the 99% of the population that is still sane) you’ll find tons of improvements, modifications, case-specific optimizations and alternatives to TCP, the workhorse of networking transport protocols since the 1970s.
Seth Noble, President and Founder of Data Expedition, Inc., believes that he can do one better. His company claims that their proprietary transport protocol, MTP, for “Multipurpose Transaction Protocol,” provides a scalable alternative to TCP that uses bandwidth more efficiently. According to Mr. Noble:

“TCP’s 1970′s data model makes dealing with this problem more difficult than it needs to be. TCP was created with the assumption that packet loss would “rarely” occur, and so it is rather fragile in our modern, congested networks. A lot of very smart people have tried for many years to patch TCP and help it cope, but it still carries its 30 year old legacy with it.”
“MTP/IP was designed from scratch to operate in congested environments where packet loss and other network problems are common. As a result, MTP/IP does an exceptionally good job of quickly AND correctly identifying whether or not data has really been lost and then recovering that data with little or no disruption.”

(Continued…)


In order to preserve data integrity, TCP uses a “triple handshake” – the client sends a request to the server, the server sends an acknowledgement and request back to the client, and the client sends an acknowledgement back to the server, and then, and only then, starts sending data. Furthermore, the packet payloads start small in size but progress geometrically – until a packet is dropped or is transferred incorrectly. Then the packet payloads are scaled back to the last previous successful payload. A few missed packets in a row, and the process starts again from the beginning. For that reason, when graphing TCP performance, it shows a wave-like pattern with peaks and valleys – valleys which show theoretical underutilization of the pipe. However, TCP is very good at making sure that all the packets get to the destination, in the right order.
The other main protocol used is UDP, which is typically used in voice, video, gaming, and other “real time” applications, where a packet dropped every now and then really doesn’t matter so much as the overall speed of the application. UDP has no acknowledgements and if a packet is dropped, it is gone. On the other hand, UDP typically fills up the pipe and is much faster than TCP because there’s no need for the triple-handshake.
So TCP is used when data integrity is most important, and UDP is used when data integrity is not as important as speed and utilization. The holy grail, of course, would be a transport protocol that has the speed of UDP with the data integrity of TCP.
MTP uses UDP as its base, but somehow has mechanisms to insure data integrity as well. We asked Mr. Noble to elaborate, but he mentioned that while error correction and flow control (to prevent MTP from interfering with either TCP or plain UDP traffic) were implemented into MTP, the patents on MTP are still pending and couldn’t go into the proprietary specifics, but he stated that “One of things that sets MTP/IP apart is that it is able to perform this recovery without disrupting the flow of data.” It’s anyone’s guess as to how, but there could be a number of ways this is implemented, but it’s not hard to visualize a few ways to do so.
So, theoretically, at least, using MTP – and other protocols like it – instead of TCP in your enterprise applications could help with getting more utilization from your network links. However, utilization is not a proxy for performance. Perhaps MTP’s error correction – shrouded in patent pending mystery as it is – still takes quite a bit of time. Just because the network link is fully utilized doesn’t mean that you necessarily get the full package any faster. There are inefficiencies – like corrupted data and packet resends that can occur in any transport protocol but which still use the network link. Whether this is a significant increase in a significant number of situations is yet to be seen.
It’s always good to see improvements in data transfer protocols and innovation in the network space – but no one thing can act as a cure-all.

, , , , , , ,

Comments are closed.