[p2p-hackers] UDP file transfer link speed identification

[David Barrett]

Greg Bildson wrote:
> This certainly worked but suffered from fairly poor performance given
> that there is an ack for each packet.

Thanks for the overview, Greg, I understand now.  But I'm curious about
your ack/packet performance statement.  Do you mean it consumes an
unnecessary amount of upstream bandwidth, or do you mean it actually
obtrains lower throughput?

After a lot of research, I've finally settled on an approach much like
the DCCP "TCP-like" congestion-control profile.  In essence it uses
selective ACK, cwnd, pipe, ssthresh, and other hallmarks of TCP
congestion control.  However, it doesn't offer reliability, thus
offering an unreliable equivalent to TCP.

At the moment I use one ACK per packet.  However, the sender still sends 
many packets at a time; it doesn't wait a RTT for each new packet to be 
sent, nor does it delay delivery due to out-of-order arrival.

Thus while I'm sure this approach consumes an unfortunate amount of 
upstream bandwidth, I don't believe it actually reduces downstream 
throughput.  But I've done no head-to-head comparision against anything 
else, so I'd love your feedback on whether I'm missing some big 
downstream throughput performance penalty.  Any ideas?

-david