<br>
Hi guys,<br>
<br>
You should look the following papers which propose to add partial reliability to TFRC. Moreover, Guillaume Jourjon <br>
who is currently PhD student at the University of New South Wales has implemented and tested a real implementation <br>
of TFRC/SACK mechanism. This can be also done in DCCP/CCID3.<br>
<br>
- Ernesto Exposito, Patrick Senac, and Michel Diaz: UML-SDL modelling of the FPTP<br>
QoS oriented transport protocol. In: Proc. of International Multimedia Modelling<br>
Conference (MMM). (2004)
<br>
- Ernesto Exposito: Specification and Implementation of a QoS Oriented Transport Protocol<br>
for Multimedia Applications. PhD Thesis, LAAS-CNRS/ENSICA (2003)<br>
<br>
Emmanuel<br><br><div><span class="gmail_quote">On 01/03/06, <b class="gmail_sendername">Ian McDonald</b> <<a href="mailto:imcdnzl@gmail.com">imcdnzl@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 2/28/06, Srinivas Krishnan <<a href="mailto:shrin.krishnan@gmail.com">shrin.krishnan@gmail.com</a>> wrote:<br>> SCTP does seem to provide on the outside a very nice interface<br>> borrowing congestion control from TCP and the concept of various
<br>> streams. However, the experiences we had with SCTP are not too good,<br>> especially with the PR-SCTP. We at UNC-CH wanted a protocol that lets<br>> choose on the application layer conditions whether we wanted a fully
<br>> reliable protocol or just a best-effort protocol. Unfortunately the 2<br>> implementations of SCTP: SCTPLIB (a user level package) or the kernel<br>> level implementation in Linux do not fully support partial reliability
<br>> or a way of making per packet/object decision of whether we wanted<br>> full reliability, partial etc.<br>><br>> In the end we rolled out our own protocol based on UDP using TFRC as a<br>> congestion control algorithm (based it on the sender side). The
<br>> protocol lets us choose whether we wanted to provide full reliability,<br>> partial reliability based on the application. We even have a module<br>> which does a form of congestion control in the application itself.
<br>> This is for a video adaptation and hence based on latency we always do<br>> not need to send the next packet as the time for display on the client<br>> might have passed.<br><br>I am doing a similar thing but basing it in the transport layer. It
<br>will check whether the packet is past expiry time before sending and<br>will also weight control packets higher than audio with video being<br>the lowest.<br><br>I am working with using DCCP CCID3 on Linux at present which is
<br>similar in performance I would assume to UDP using TFRC as CCID3 is<br>TFRC based. Have you looked at DCCP? You might be able to choose<br>whether you want reliable or unreliable using a mixture of switching<br>between TCP and DCCP or were you wanting to switch midstream?
<br>><br>> I will describe some more of our work on video adaptation on a separate post.<br><br>Will be interested in seeing.<br><br>Ian<br>--<br>Ian McDonald<br>Web: <a href="http://wand.net.nz/~iam4">http://wand.net.nz/~iam4
</a><br>Blog: <a href="http://imcdnzl.blogspot.com">http://imcdnzl.blogspot.com</a><br>WAND Network Research Group<br>Department of Computer Science<br>University of Waikato<br>New Zealand<br></blockquote></div><br><br clear="all">
<br>-- <br>Emmanuel
Lochin <a href="http://lochin.new.fr/">http://lochin.new.fr/</a> <a href="mailto:emmanuel.lochin@nicta.com.au">emmanuel.lochin@nicta.com.au</a>
<br>Networks and Pervasive Computing Research Program<br>National ICT Australia Ltd<br>Locked Bag 9013, Alexandria, NSW 1435<br>Australia<br>---<br>"This email and any attachments are confidential. They may contain legally
<br>privileged information or copyright material. You should not read, copy, use<br>or disclose them without authorisation. If you are not an intended<br>recipient, please contact us at once by return email and then delete both
<br>messages. We do not accept liability in connection with computer virus,<br>data corruption, delay, interruption, unauthorised access or unauthorised<br>amendment. This notice should not be removed"