Date: Thu, 7 Dec 2006 17:13:35 +0800 From: "maillist ifiaas" <maillist.ifiaas@gmail.com> To: "Andre Oppermann" <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. Message-ID: <161d69110612070113g7dcf027dj532cffdcd633a4a@mail.gmail.com> In-Reply-To: <4577D858.4010300@freebsd.org> References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <m21wncv66z.wl%gnn@neville-neil.com> <4577D858.4010300@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you Andre. You explain it clearer than me. Yes, TCP's interweaving with retransmission scares people from multimedia streaming point of view. So we find a way to remove retransmission in TCP. Acctually it turns out to be easier than it looks. We only add another 750 lines of code in the source, including the debugging and preprocessor directives. We are trapped on the delay ACK problem, and don't know how our code affects the delay ACK action in original TCP. Through experiments, we find TCP Urel delayed more ACK than TCP Sack. For Sack, the delack / nondelack which are triggered by incoming data segment is almost 1:1 (in fast track), but for TCP Urel, the same ratio is around 2:1. -gavin On 12/7/06, Andre Oppermann <andre@freebsd.org> wrote: > 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?161d69110612070113g7dcf027dj532cffdcd633a4a>