Date: Thu, 07 Dec 2006 10:01:12 +0100 From: Andre Oppermann <andre@freebsd.org> To: gnn@freebsd.org Cc: freebsd-net@freebsd.org, maillist ifiaas <maillist.ifiaas@gmail.com> Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. Message-ID: <4577D858.4010300@freebsd.org> In-Reply-To: <m21wncv66z.wl%gnn@neville-neil.com> References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <m21wncv66z.wl%gnn@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
gnn@freebsd.org 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4577D858.4010300>