Faster Bulk Transfer Starring: *UDP*

Study and Evaluation of 4 UDP protocols

The QUANTA web page states that Quanta was motivated by prior work in adaptive networking for Tele-Immersion. RDUDP addresses just one aspect, bulk transfer, of that bigger project. Tele-Immersion is described[1] as "the integration of collaborative virtual reality (VR) with audio and video conferencing in the context of data-mining and significant computation". The authors are working to provide an equation similar to TCP's bandwidth*delay product to allow a prediction of RBUDP performance. In their effort to discover this equation, they have discovered there are many reasons that the data rate falls short of that expected based on available network bandwidth alone. One of the problems they have found relates to the fact that end systems often have trouble keeping up with the increased network bandwidth. Reliable Blast UDP has two goals.

3.4.1. use of TCP/UDP channel(s)
The sender briefly acts as a server by getting a TCP socket to listen for a client connection request. As soon as one client request is received, an accept is issued and the resulting TCP channel is used for the transmission of control and error information. A UDP channel using a default port is obtained for the sending/receiving of data.
3.4.2. rate-control algorithm
The most important input parameter is the sendRate of the UDP blasts which is specified by the user on the command line in Mbs. Packet size is payloadSize(1452) + the size of the packet header. The sender calculates:
usecsPerPacket = 8 * payloadSize/sendRate
and then uses usecsPerPacket to time each sendmsg():
gettimeofday(&now, NULL);
if (USEC(&start, &now) < usecsPerPacket * i)
At present, there is no backing off from the user specified sending rate due to losses/congestion.
3.4.3. data sending algorithm
The sender transmits an entire chunk of data at the user-specified rate using UDP datagrams and sendmsg(). At the end of the data transmission, the sender then transmits an endOfUdp message via the TCP channel. The receiver responds by sending a bitmap tally of the received packets. If there are no missing packets, the first byte is a 1 otherwise it is a 0. The sender responds by resending any missing packets and the process repeats itself until all data has been received.
3.4.4. data receiving algorithm
The receiver uses a timed(20 secs) select() to monitor both UDP and TCP sockets. If a timeout occurs, the transfer is assumed to be finished! With each recvmsg(), the receiver must update its bitmap tally of received packets so that at the end that information can be sent to the sender.
3.4.5. unique features
QUANTA uses the iovec structure with sendmsg/recvmsg over the UDP channel.
The errorBitmap algorithm appears to be accurate, efficient and fast. As mentioned, the receiver updates it's bitmap--one bit per packet--every time a packet is received. Upon the receipt of the endOfUdp message, the receiver transmits the bitmap to the sender who inspects the bitmap to discover missing packets which it immediately retransmits.
Since RBUDP does not have a file transfer, it remains to be determined how buffers will be handled in order to keep data flowing and the pipe full.
Also mentioned in the literature but as yet not implemented is some form of error correction.