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

[Michael Tuexen]

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"
>