Faster Bulk Transfer Starring: *UDP*
Study and Evaluation of 4 UDP protocols
3.4. RBUDP or QUANTA
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.
- First, to keep the network pipe as full as possible during bulk data transfer.
- Second, to avoid TCP's ACK overhead by sending
acknowledgments only at the end of the transmission phase.
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():
while(!done)
gettimeofday(&now, NULL);
if (USEC(&start, &now) < usecsPerPacket * i)
{}
else
sendmsg()
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.