From owner-freebsd-net@FreeBSD.ORG Thu Dec 7 18:37:39 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 6CDBA16A51F for ; Thu, 7 Dec 2006 18:37:39 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57CC743CCB for ; Thu, 7 Dec 2006 18:36:28 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 07 Dec 2006 10:37:20 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB7IbHeY009528; Thu, 7 Dec 2006 10:37:17 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB7IbHin005785; Thu, 7 Dec 2006 10:37:17 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:37:17 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:37:16 -0800 Message-ID: <45785F2C.7040004@cisco.com> Date: Thu, 07 Dec 2006 13:36:28 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: maillist ifiaas References: <161d69110612060709n3bf99bd4y47d94b021b8f1d02@mail.gmail.com> <4577D858.4010300@freebsd.org> <2786D1DE-E8FA-490C-AFF7-E458E262AEF7@lurchi.franken.de> <161d69110612070242p612e2318ya8d285a15a54e9fc@mail.gmail.com> <4578057B.9080002@cisco.com> <161d69110612070451o6945c7c0y9cf7a7e8b6b7225d@mail.gmail.com> In-Reply-To: <161d69110612070451o6945c7c0y9cf7a7e8b6b7225d@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2006 18:37:16.0861 (UTC) FILETIME=[B87176D0:01C71A2E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2307; t=1165516637; x=1166380637; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Urel, =20a=20TCP=20option=20for=20Unreliable=20Streami ng.=20Need=20your=20help. |Sender:=20; bh=CtHGg+YvnaLS3DeSHdC8CpwFqmuCtXmHXzm+OyAKmRg=; b=cHs5H8wKWiyqUlSczyLuJNVLXUNqPbpy+vnWLKDueQhq0z6tYkwhWPx/d4VpAmFd8FXUEpWI l4jPxrLtNd0zoUoYdN6XnmbnX0ws9RfCU/f4qejl2NnBvcbE61gz7E9s; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim1002 verified; ); 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 18:37:39 -0000 maillist ifiaas wrote: > Thanks Randall. > > Am I right to say that, in SCTP, the loss information is reported to > the sender, instead of the receiver? Correct... the sender is notified of the loss... you could tell the receiver as well.. but the current BSD implementation does not do this .. the info is there .. just not reported :-D > > Btw, TCP Urel is a option. To use it, you have to add something like, > int rc = setsockopt( inSettings->mSock, IPPROTO_TCP,TCP_URE, (char*) > &val, len ); > to enable Urel option in TCP. Yep.. I thought so, so basically it is no different than having to set the prefered send option.. with a socket opt.. and then a one line change to add IPPROTO_SCTP to the socket() call .. No different coding wise I think.. > > I still think that partial reliability should be performed in the > application layer. Although transport layer knows more about the > channel condition, but they can either be reported to the application > (like we did on segment loss in TCP Urel), or be infered by > application (e.g. estimating the current bitrate by looking at the > buffersize). As QoS is only meaningful to application, allowing > flexibilty of implementing QoS (such as partial relaibility) mechenism > in application layer rather than transport layer, looks much natrual to me. Then why modify TCP? R > > -gavin > > On 12/7/06, Randall Stewart wrote: > >> maillist ifiaas wrote: >> > 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 >> >> Yep.. you subscribe for a notification event and SCTP will >> return you the data that was not sent. >> >> So not only does it let you know you can actually let >> SCTP hold and return the data that did not get >> acknowledged.. The API also has a context so you >> can attach a user defined 32 bit value to the >> data.. to say bind a pointer to an object to >> the actual data... for lookup or other stuff :-) >> >> R >> > >> >> >> >> -- >> Randall Stewart >> NSSTG - Cisco Systems Inc. >> 803-345-0369 803-317-4952 (cell) >> > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell)