From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 09:01:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C368016A522 for ; Thu, 7 Dec 2006 09:01:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90CE843CCC for ; Thu, 7 Dec 2006 09:00:23 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 31456 invoked from network); 7 Dec 2006 08:49:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Dec 2006 08:49:39 -0000 Message-ID: <4577D858.4010300@freebsd.org> Date: Thu, 07 Dec 2006 10:01:12 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: gnn@freebsd.org References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, maillist ifiaas Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 09:01:24 -0000 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