Transport protocols and bulk file transfer

[Yunhong Gu <>]

Hi, stas

> Could you tell us more about the approach that you tried?  Did you
> look at delay-base_delay, packet train dispersion, or something else?

Our current approach can be found in the following two papers:
http://www.cs.uic.edu/~ygu/paper/udt-design-sc04-v8.pdf
http://www.cs.uic.edu/~ygu/paper/gridnet-v8.pdf

It is a pure loss based approach based on a AIMD variant.

Previously we also use packet delay as congestion indication. The idea is
simple. The receiver side checks the packer arrival pattern, if there is
an increasing trend in the packet delays, it sends back a delay warning
message to the sender. This delay warning message triggers similar action
as an negative acknowledgement does, as described in the first paper
above.

The check of increasing trend in packet delay uses the method introduced
by Pathrate
http://www.cc.gatech.edu/fac/Constantinos.Dovrolis/Papers/ton_slops.pdf.

For example, if you see the packet delay sequence is like 100, 101, 102,
103, 104, etc, you may guess that the queue is filling up. (Of course
this example is too ideal :) ).

I am still interested in similar mechanism and I am testing new method to
be used in UDT3. Due to similar reason you metioned in the design doc, I
want to use a supportive delay based mechanism to prevent the loss based
algoroithm from increasing RTT too much.

> I'm not familiar with Windows.  What's overlapped I/O and file
> transfer?
>
> At the last call, we were talking about interactive applications.
> Socket API doesn't give the application feedback on the sending rate
> -- instead, TCP just blocks (or doesn't accept data if you set the
> nonblocking option) if it can't put it in the sending buffer.  This is
> fine for certain things.  I think an additional advisory mechanism is
> needed for interactive applications.  In addition, a socket-like API
> (connect/accept then write/read) limits the implementation choices and
> makes copies that are often unnecessary; sendfile() is a good idea (as
> it lets you share disk and network buffers instead of duplicating them
> and copying needlessly), but sockets don't let you have corresponding
> receivefile().


Overlapped IO is a semantic to avoid memory copy between user buffer and
protocol buffer in send and recv. It tries to read data from and write
data to the user buffer directly.

I did include a recvfile() API in UDT 2. In addition, UDT 2 provides
performance monitoring API so that applications can query the internal
variables of UDT (e.g., RTT, cwnd size, inter-packet time, etc) and the
statistics of performance. I think this is similar to your idea on API,
although I do not exact understand the part of "advisory mechanism" and
"interactive applications"

If you are interested, here is an online documentation of UDT API.
http://www.cs.uic.edu/~ygu1/
(need Java Script support to view, see the Reference part of the doc).

I support socket-like API becasue this is easier for users to translate
their TCP based applications to the new protocols.

Thanks,
Gu