[e2e] application layer -SCTP!!!!

[Randall Stewart]

Srinivas:

Well.. I can't speak for the Linux and u-Space stack's.. so
I don't know the details.. but the FreeBSD-SCTP stack does
support three different models of partial-reliability.

1) Time based, when you send data you specify howmany milliseconds
    the data is good for.

2) Buffer bounded, when you send data you specify the maximum buffer
    size (of your sendbuf) you wish to consume, when you reach that
    max other sends that were sent buffer bounded may get "skipped" to
    free up space...

3) Retransmission based, where you specify the maximum number of
    retransmissions you want made.. so for example if you specify
    0, you get one and only one transmission and then the data
    is skipped (if a retran was required).

If you want to get FreeBSD and play with it contact me offline and I
can give you pointers on what options you need on the send calls..

R

Srinivas Krishnan wrote:
> SCTP does seem to provide on the outside a very nice interface
> borrowing congestion control from TCP and the concept of various
> streams. However, the experiences we had with SCTP are not too good,
> especially with the PR-SCTP. We at UNC-CH wanted a protocol that lets
> choose on the application layer conditions whether we wanted a fully
> reliable protocol or just a best-effort protocol. Unfortunately the 2
> implementations of SCTP: SCTPLIB (a user level package) or the kernel
> level implementation in Linux do not fully support partial reliability
> or a way of making per packet/object decision of whether we wanted
> full reliability, partial etc.
> 
> In the end we rolled out our own protocol based on UDP using TFRC as a
> congestion control algorithm (based it on the sender side). The
> protocol lets us choose whether we wanted to provide full reliability,
> partial reliability based on the application. We even have a module
> which does a form of congestion control in the application itself.
> This is for a video adaptation and hence based on latency we always do
> not need to send the next packet as the time for display on the client
> might have passed.
> 
> I will describe some more of our work on video adaptation on a separate post.
> 
> *********************************
> Srinivas Krishnan
> 
> Graduate Student
> Dept. Of Computer Science
> UNC-Chapel Hill
> ++++++++++++++++++++++++++++++++
>  Phone:
>    **Office: (919) 962-1920
>    **Cell:    (585)295-3359
>  Email: krishnan at cs.unc.edu, shrin.krishnan at gmail.com
> ++++++++++++++++++++++++
>  Web: www.cs.unc.edu/~krishnan
>  **************************************
> 
> 


-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)