Date: Thu, 7 Dec 2006 11:46:34 +0800 From: "maillist ifiaas" <maillist.ifiaas@gmail.com> To: freebsd-net@freebsd.org Cc: gnn@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. Message-ID: <161d69110612061946w16c292b6ja9a8bd6b742d5885@mail.gmail.com> 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
Hi George, Compare to SCTP, TCP Urel is much simpler. Drawback is the (1) lack of multihoming, (2) directly implmentation of partial reliabiliity. These drawbacks, however, allows more flexibility for usage. I am not very familiar with SCTP. I suppose the multihoming support is the key for SCTP to support multipath streaming. But not all client (say, home users) has multiple IP address: seldom of them use two network card, ISP less willing to offer multiple IP addresses to single user, or the Cable Modem/home-gateway which has only one IP address to the outside world. Therefore, I suppose that multpath streaming to home users, the largeset group that multimedia application should serve, is only feasible now at the application layer. I.e. a transport protocol may be better off to offer the flexibility for multipath streaming, rather than do it by yourself. TCP Urel realize congestion controlled unreliability on single path. It provide segment loss information to the receiver; therefore if the application want, they are able to do retranmission by themselves. This simplisity gives the free of retransmission to the application: to retransmit or not, and from where to retranmit? One pontential application is the Distributed Media Streaming (or Multi-Source Streaming), where the receiver should have the freedom to decide from which sender the retranmission should be conducted. We believe TCP Urel has a niche fit to this type of applications. Another benifit from TCP Urel, is that, it inherents the API from TCP. Therefore, many exsiting streaming programs that currently using TCP for multimedia stremaing purpose can acctually be changed to use Urel by change a few lines in the source code, to set socket options, and to handle same simple metadata at the receiver. Very simple modifcation are needed. The third benifit is that, since Urel is only an option on TCP. When the TCP evolves in the future, say, the congestion control is modified a bit here and there, Urel adapts to these changes. And we can anticipate that, the unreliable support from Urel in that version of TCP, will be still there. To other protocols that are designed to be friendly to TCP, they may have to be modified very carefully to retain the TCP-friendliness. Since TCP is the dominant protocol, and the keystone of the network stability, attaching the unliability function to TCP instead of creating a new protocol may be a safer and easier bet. Regards, Gavin On 12/7/06, gnn@freebsd.org <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? > > Best, > George >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?161d69110612061946w16c292b6ja9a8bd6b742d5885>