From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 10:43:16 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 1BA6F16A584 for ; Thu, 7 Dec 2006 10:43:16 +0000 (UTC) (envelope-from maillist.ifiaas@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05DD643E0D for ; Thu, 7 Dec 2006 10:41:11 +0000 (GMT) (envelope-from maillist.ifiaas@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so811405nfc for ; Thu, 07 Dec 2006 02:42:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TdO6IZT04kkFOqg6ZNixoAy72XqSreA2dLDAShtD5lMC/6cCcKq+DpeN36+8BmIaraajaiGAI9I3cgSaOQo2l5uufInoRbQRjSJdQMyx5bqy1WhlF5N30/AV5VzS7u9x6jlFBCSwSNCf9cqXBKfP5IcnCDSSWek2JmsZjeNNgoA= Received: by 10.49.91.6 with SMTP id t6mr3691811nfl.1165488121449; Thu, 07 Dec 2006 02:42:01 -0800 (PST) Received: by 10.48.242.15 with HTTP; Thu, 7 Dec 2006 02:42:01 -0800 (PST) Message-ID: <161d69110612070242p612e2318ya8d285a15a54e9fc@mail.gmail.com> Date: Thu, 7 Dec 2006 18:42:01 +0800 From: "maillist ifiaas" To: "Michael Tuexen" In-Reply-To: <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> Cc: 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 10:43:16 -0000 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 wrote: > 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" > > > >