[EMAIL PROTECTED] wrote:
At Wed, 6 Dec 2006 23:09:39 +0800,
maillist ifiaas wrote:
Hi friends,
This is one of my research project. Our purpose is to modify TCP to
support unreliable but congestion controlled streaming. The
motivation is pretty similar to the one of DCCP CCID2. We have
implemented a prototype on FreeBSD 5.4, and the the modifications
are limited mostly in tcp_input.c and tcp_output.c. Source code, a
paper about the design (under submission), and an Iperf modification
to test out TCP Urel, is provided on the following page:
www.comp.nus.edu.sg/~malin/
Our current stage is changing Urel into a single directional
streaming protocol, so taht it could be abosolutely fair with
default TCP Sack, in FreeBSD. But we found after all the
modifications (on single directional streaming), Urel generates less
ACK than normal Sack, making it under utilized when competing to TCP
Sack. About only 3 out of 10 tries, Urel take the same throughput as
Sack. The reason seems to lying in the Delay ACK code, in
tcp_input.c. Because, when we turn off the Delay ACK option, using
sysctl command, Urel and Sack play fairly. However after days of
looking at the code, we failed to find the secret... Therefore, I
turn to you, the specialists of the TCP code in FreeBSD. Hope you
can help us to find the bug of our code. Any suggesion, comments, is
appreciated.
For details of how the code is implemented, how our experiment is
conducted, you may need to spend one or two hours to browse through
our paper, and the source code.
How is this different from the recently integrated SCTP?
It doesn't try to retransmit at all. A lost segment is lost and
resending it would be pointless for realtime content. On the other
hand you don't want to blast the network at a fixed rate and so
this protocol wants to use a congestion control algorithm to back
off when bandwidth gets scarce. I haven't looked at the details
yet but my initial guess would be that the actual TCP code isn't
the best starting point. TCP is too obsessed with retransmitting
if something got lost.
--
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
