[p2p-hackers] UDP file transfer protocol peer review

[Saikat Guha]

On Fri, 2005-07-22 at 21:12 -0700, David Barrett wrote:
> Likewise, there is a similar list of options about when to decrease:
> a) When it detects a single packet loss
> b) When it is unable to download at the requested rate for some period
> ...
> but I'm concerned about the impact of wireless networks 

In a wireless scenario, [1] shows that a single packet loss (a) or even
a threshold percent of packet loss within some period (b) are not good
indicators of congestion/contention -- i.e. cannot differentiate among
them. TCP uses a) and performs poorly in the wireless scenario. Instead,
[1] proposes looking at the number of _consecutive_ losses since such
losses are temporally correlated. FastTCP [2] more or less ignores
isolated losses and moreover uses delay based congestion signals. 

From your list of options, increase:a and increase:a-applied to decrease
may be interesting (similar to [1]'s proposal). Though you may want to
set the COUNT for the decrease part to something low (2-3 perhaps) to
avoid crowding out regular TCP. Also, if you haven't already, I'd
suggest looking at FastTCP.


[1] http://lecs.cs.ucla.edu/~cerpa/papers/time-estimation-tech-
report.pdf ... there is a MobiHoc '05 version of this paper somewhere
[2] http://www.cs.caltech.edu/~weixl/research/control/ton2004.pdf


-- 
Saikat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050723/6975587d/attachment.pgp