[p2p-hackers] Using UDT for swarming

Serguei Osokine Serguei.Osokine at efi.com
Tue Jan 25 20:29:07 UTC 2005


On Tuesday, January 25, 2005 Matthew Kaufman wrote:
> It was designed to outperform traditional TCP over large delay*
> bandwidth networks, but actually gives TCP the edge in more typical 
> network settings.

	Well, that depends on what "large delay*bandwidth" is. Even the
slow link might fall into this category if the RTT is high enough. So
to be fair to UDT, it might prove to be quite applicable for a typical
concurrent upload situation. Like I said, I did not do any careful
analysis of the UDT and of its behaviour on the slower links and was
wondering if anyone did and whether there are any better alternatives.

> And if your design parameter is large numbers of streams with vastly
> different RTTs and you wanted to improve over TCP's handling of this,
> you'd make different choices than were made for UDT.

	Yeah, that was pretty much the reason behind my question. What 
would be these different choices? Got any pointers? The apparent UDT 
intent to optimize the gigabit transfers - possibly at the expense of
the slower streams - was a bit of a warning flag for me, too - but
I did not see any project that even asks these questions, much less
answers them. One possible exception might be all this FEC vodoo in
the multicasting group, but for me it feels like a bit of an overkill
for the job (even if I would be sure that FLUTE/ALC/LCT stack really
does resolve these issues, which I'm not).

	Best wishes -
	S.Osokine.
	25 Jan 2005.

-----Original Message-----
From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org]On
Behalf Of Matthew Kaufman
Sent: Tuesday, January 25, 2005 11:59 AM
To: 'Peer-to-peer development.'
Subject: RE: [p2p-hackers] Using UDT for swarming


This protocol is clearly designed to operate in something other than today's
consumer Internet. It was designed to outperform traditional TCP over large
delay*bandwidth networks, but actually gives TCP the edge in more typical
network settings. For file transfers over actual connections you're likely
to see (unless you have a GigE plugged right into Internet2 on your desk),
TCP is a better choice, and if you need UDP for NAT traversal or other
reasons, there are better performing (and simpler to implement, as this
requires things like fine-grained clocks) choices. And if your design
parameter is large numbers of streams with vastly different RTTs and you
wanted to improve over TCP's handling of this, you'd make different choices
than were made for UDT.

Matthew Kaufman
matthew at matthew.at
http://www.amicima.com


> -----Original Message-----
> From: p2p-hackers-bounces at zgp.org 
> [mailto:p2p-hackers-bounces at zgp.org] On Behalf Of Serguei Osokine
> Sent: Tuesday, January 25, 2005 10:33 AM
> To: p2p-hackers at zgp.org
> Subject: [p2p-hackers] Using UDT for swarming
> 
> 
> 
> 	People, does anyone have an opinion about UDT?
> 

_______________________________________________
p2p-hackers mailing list
p2p-hackers at zgp.org
http://zgp.org/mailman/listinfo/p2p-hackers
_______________________________________________
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences



More information about the P2p-hackers mailing list