Urel, a TCP option for Unreliable Streaming. Need your help.

[maillist ifiaas]

Michael,

In PR-SCTP where retranmission is set off, does it allows the
applications to know which part of data is lost in the stream?
Thanks

-gavin

On 12/7/06, Michael Tuexen <Michael.Tuexen at lurchi.franken.de> wrote:
> Hi Andre,
>
> see my comments in-line.
>
> Best regards
> Michael
>
> On Dec 7, 2006, at 10:01 AM, Andre Oppermann wrote:
>
> > gnn at 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.
> SCTP has a extension called PR-SCTP, which is implemented in BSD
> and can be used to limit the number of retransmissions of a
> DATA chunk to 0. The service you mention above is therefore available
> in SCTP.
> >
> > --
> > Andre
> >
> > _______________________________________________
> > freebsd-net at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> >
>
>