[e2e] application layer -SCTP!!!!

Emmanuel Lochin emmanuel.lochin at gmail.com
Wed Mar 1 21:02:58 PST 2006


Hi guys,

You should look the following papers which propose to add partial
reliability to TFRC. Moreover, Guillaume Jourjon
who is currently PhD student at the University of New South Wales has
implemented and tested a real implementation
of TFRC/SACK mechanism. This can be also done in DCCP/CCID3.

- Ernesto Exposito, Patrick Senac, and Michel Diaz: UML-SDL modelling of the
FPTP
QoS oriented transport protocol. In: Proc. of International Multimedia
Modelling
Conference (MMM). (2004)
- Ernesto Exposito: Specification and Implementation of a QoS Oriented
Transport Protocol
for Multimedia Applications. PhD Thesis, LAAS-CNRS/ENSICA (2003)

Emmanuel

On 01/03/06, Ian McDonald <imcdnzl at gmail.com> wrote:
>
> On 2/28/06, Srinivas Krishnan <shrin.krishnan at gmail.com> 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 am doing a similar thing but basing it in the transport layer. It
> will check whether the packet is past expiry time before sending and
> will also weight control packets higher than audio with video being
> the lowest.
>
> I am working with using DCCP CCID3 on Linux at present which is
> similar in performance I would assume to UDP using TFRC as CCID3 is
> TFRC based. Have you looked at DCCP? You might be able to choose
> whether you want reliable or unreliable using a mixture of switching
> between TCP and DCCP or were you wanting to switch midstream?
> >
> > I will describe some more of our work on video adaptation on a separate
> post.
>
> Will be interested in seeing.
>
> Ian
> --
> Ian McDonald
> Web: http://wand.net.nz/~iam4
> Blog: http://imcdnzl.blogspot.com
> WAND Network Research Group
> Department of Computer Science
> University of Waikato
> New Zealand
>



--
Emmanuel Lochin      http://lochin.new.fr/      emmanuel.lochin at nicta.com.au
Networks and Pervasive Computing Research Program
National ICT Australia Ltd
Locked Bag 9013, Alexandria, NSW 1435
Australia
---
"This email and any attachments are confidential. They may contain legally
privileged information or copyright material. You should not read, copy, use
or disclose them without authorisation.  If you are not an intended
recipient, please contact us at once by return email and then delete both
messages.  We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment.  This notice should not be removed"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060302/3ec67160/attachment-0001.html


More information about the end2end-interest mailing list