Date: Thu, 07 Dec 2006 07:05:59 -0500 From: Randall Stewart <rrs@cisco.com> To: maillist ifiaas <maillist.ifiaas@gmail.com> Cc: freebsd-net@freebsd.org, gnn@freebsd.org Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. Message-ID: <457803A7.4000706@cisco.com> In-Reply-To: <161d69110612061946w16c292b6ja9a8bd6b742d5885@mail.gmail.com> References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <m21wncv66z.wl%gnn@neville-neil.com> <161d69110612061946w16c292b6ja9a8bd6b742d5885@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
maillist ifiaas wrote:
> 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.
hmm... I don't think I agree here :-)
>
> I am not very familiar with SCTP
I am a little bit :-D
. 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.
Hmm.. again I disagree.. SCTP (plain vanilla without partial
reliability) offers 3 key features, you hit on one above:
a) Mulitihoming.. and Jana's work on CMT shows that even if
a app sender creates two connections on different paths
and has "perfect" knowledge SCTP with CMT will outperform
the two connections... Of course CMT is still not ready
for the internet due to shared path detection.. but the
point is the transport knows more than the app can so
I think multi-homing belongs in the app.
b) Multi-streaming.. this is a big one, since head of line
blocking is a serious problem when an app moves lots
of parrallel things over a connection.
c) Unordered data .. which speaks for itself...
>
> 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.
And if you are doing partial reliability you can do the same
exact thing.. you get msg loss information up to the app (if your
interested in it) and thus the app could do further retransmissions :-)
Yet at the same time you get a congestion controlled transport that
is fair with TCP or other SCTP connections...
You have 3 options for partial reliablity..
a) Timed based.. send this and get it across within the next
N ms or forget it.
b) Buffer bounded.. when I get X in queue start skipping forward
data.
c) Number of retransmissions based.. transmit it once and retransmit
it at least N times.. where N can be 0..
>
> 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.
Same is true for SCTP.. you can use the TCP model, if you so
desire .. you would need to do one socket option to turn
on the type of partial reliability that you want.. and that
would be it..
In fact if you so desire you can even make your connection
look like one big stream of bytes too (of course that
takes an additional socket options)..
>
> 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.
Same is true for PR-SCTP.. we already have an option (compile wise is
BSD) to turn on Sally Floyds High_Speed TCP congestion control in
SCTP.. and if you do this, you automatically get it for PR-SCTP
as well. Note that you also get all the other features
such as a much better authentication (think TCP-MD5 but designed
right), dynamic address capability (for those mobile or IPv6
hosts) and any other features.. all for free..
Note there will be some new CC algorithms making its way into
our SCTP stack in the future.. I just have been to busy to
get the "pluggable" congestion control in... but I will here
eventually... but when I do, unlike linux, RFC2581 (the current
CC) will be the default... :-)
>
> 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.
And I can just hear Joe Touch's thoughts on this.. Protocol 6 is
taken.. choose another one :-D
In general, you use TCP and expect to get a reliable CC protocol.
I don't see the value of changing this without a specific
option the user has to do to enable it... and for that
matter it IMO would be better to use something like DCCP
so that you KNOW you are using it or SCTP of course :-D
R
>
> 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
>>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?457803A7.4000706>