[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Urel, a TCP option for Unreliable Streaming. Need your help.
- To: maillist ifiaas <maillist_(_dot_)_ifiaas_(_at_)_gmail_(_dot_)_com>
- Subject: Re: Urel, a TCP option for Unreliable Streaming. Need your help.
- From: Randall Stewart <rrs_(_at_)_cisco_(_dot_)_com>
- Date: Thu, 07 Dec 2006 13:36:28 -0500
- Authentication-results: sj-dkim-1; header_(_dot_)_From=rrs_(_at_)_cisco_(_dot_)_com; dkim=pass (sig from cisco.com/sjdkim1002 verified; );
- Cc: freebsd-net_(_at_)_freebsd_(_dot_)_org
- 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_(_at_)_cisco_(_dot_)_com; z=From:=20Randall=20Stewart=20<rrs_(_at_)_cisco_(_dot_)_com> |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;
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 <rrs_(_at_)_cisco_(_dot_)_com> 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 <or> 803-317-4952 (cell)
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
_______________________________________________
freebsd-net_(_at_)_freebsd_(_dot_)_org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe_(_at_)_freebsd_(_dot_)_org"
Visit your host, monkey.org