<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>Hi there,</FONT></DIV>
<DIV><FONT size=2>I am a research student trying to develop a rate-based
transport protocol primarily catered for streaming video on the
internet. At the moment I am employing a rate adjustment mechanism
based on LIMD. My protocol in a nutshell, the sender transmits packets at an
everage rate and the receiver monitors the reception of these packets. After a
period (typically after a SRTT), like RTP the receiver sends a report back
to the sender. If there is no packet loss experienced, the sender increases its
rate linearly otherwise it halves its rate.</FONT></DIV>
<DIV><FONT size=2>At the moment, what I was hoping you guys could advise me is
on the rate increase step. I realise that during the congestion avoidance
state, most TCP implementations increase their window by one
packet after each RTT. As a result, I decided to employ a pretty similar
rate increase control action as shown in the equation below.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Rate_new = Rate_old + (TLastUpdate*
PacketSize)/(SRTT*SRTT)</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>where TLastUpdate = Time elapsed since last rate
update.</FONT></DIV>
<DIV><FONT size=2>I believe this would mimic TCP's rate increase step quite
resonably. This or something similar has also been used by others in
their rate based transport protocol. </FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>However, I've found in my simulations that such a mechanism
could induce severe oscillation in the rate particularly when used with
rate-halving multiplicative decrease. This is mostly obvious when a huge
PacketSize is used and the path's RTT is small. A PacketSize = 1000 bytes
and a RTT = 100 ms would give a rate increase of 80,000 bits/s for each RTT. I
am sure a continual increase by such rate could be quite
drastic for a narrow bottleneck link and as a result the flow might be
vulnerable to regular packet loss and rate halvings.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>I was hoping if anybody could share a light on this and advise
me on a more suitable rate increase technique, particularly for
streaming. Has anyone done any work on the implications and stability
of this 'TCP like' rate increase? I do realise that the PacketSize, RTT,
SRTT and the Bottleneck Bandwidth plays an important role in deciding
on the suitable amount to increase the rate at each control step. Has
anyone come up with a more adaptive rate increase technique?
</FONT></DIV>
<DIV><FONT size=2>Your help and advice is very much appreciated. I thank you all
in advance.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Regards,</FONT></DIV>
<DIV><FONT size=2>Jeevandra Sivarajah</FONT></DIV></BODY></HTML>