From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 09:42:59 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 277C716A417; Thu, 7 Dec 2006 09:42:59 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from ilsa.franken.de (mail-n.franken.de [193.175.24.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E151F43CA5; Thu, 7 Dec 2006 09:42:07 +0000 (GMT) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [192.168.1.15] (p508FDDC2.dip.t-dialin.net [80.143.221.194]) by ilsa.franken.de (Postfix) with ESMTP id 6AA0E2464B; Thu, 7 Dec 2006 10:42:56 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <4577D858.4010300@freebsd.org> References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Date: Thu, 7 Dec 2006 10:42:59 +0100 To: Andre Oppermann X-Mailer: Apple Mail (2.752.2) Cc: gnn@freebsd.org, maillist ifiaas , freebsd-net@freebsd.org 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:42:59 -0000 Hi Andre, see my comments in-line. Best regards Michael On Dec 7, 2006, at 10:01 AM, Andre Oppermann wrote: > 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. 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >