Bob Harris:
> With coding, there is no need for a back channel from the
receiver-to-sender for
> resends.
Forward error correction has its place, but it is no excuse for eliminating
the feedback necessary to perform proper congestion control. There are
numerous reasons why protocols which fail to perform congestion control
(including RTP, as used for VOIP) are a bad idea for both the individual
user (end-link saturation, excess queueing, impact on the congestion
management of parallel TCP flows, routers which drop or de-prioritize
nonconforming flows, etc.) and the Internet as a whole (router queueing,
congestion collapse, etc.).
TCP or protocols with TCP-friendly congestion management are mandatory for
bulk transfer of data. TCP is the easy answer. Reimplementing TCP on UDP or
using TFRC on UDP is the not-so-easy answer.
My personal (albeit biased) suggestion is to use amicima's MFP, which gets
you congestion controlled delivery for both reliable *and* unreliable flows,
among many other features.
Matthew Kaufman
[EMAIL PROTECTED]
http://www.amicima.com
_______________________________________________
p2p-hackers mailing list
p2p-hackers@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
