[e2e] link between Kelly's control and TCP's AIMD

[Lisong Xu]

Here is a related paper by RPI, which introduces uniformly distributed 
delays to TCP packets.
http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/randomized-infocom.pdf

Regards
Lisong

Sireen Habib Malik wrote:

> Hi,
> 
> First thanks to Mr. Cannara's who sent me very valuable research papers 
> in response to my last email. Thanks also for zipping them.
> For a person who decided to improve his understanding of TCP only a few 
> days ago, i do feel that the sent papers cover a remarkable breadth of 
> the top TCP research. Anyone also walking to same line, please send me 
> an email, i will forward the papers.
> I come to the point Mr. Cannara raised in his email(s): losses.
> 
> If the key word is performance then my feeling is that more than losses, 
> TCP's bottleneck is its dependence on RTT. Secondly, its tendency to 
> send segments in correlated manner causing burstiness in the small time 
> scales leading to higher queue build-up.
> 
> I think the important point to approach TCP modelling is not to straight 
> away go to the calculation of losses but first understand its key 
> property: bandwidth sharing.
> For example, we have N flows over C capacity link with B buffer. The 
> flows are "not" snychronized and are saturating the link.
> Then for each connection,
> 
> average_rate = C/N.
> 
> Immediately one can establish the average_window.
> 
> average_window/RTT = C/N
> 
> If i want to make it even more precise.
> 
> average_window/(RTT+2B/C) = C/N,
> 
> or average_window= (RTT*C + 2B)/N,
> 
> as each connection will see full buffer before loosing a packet, B/C is 
> the time to drain the buffer. I have added two buffer delays assuming 
> symmetric bidirectional traffic. Actually it should be RTT+kB/C, where k 
> indicates the traffic assymetry.
> This is quite intuitive as the total pipe volume and the buffer space 
> will be shared by N flows.
> 
> For constant RTT+kB, we have the average_window inversely proportional 
> to the number of connections. A linear relationship! This is very nice.
> If not for its dependence on RTT, the protocol looks very FAIR!
> 
> Now TP= avg_window/(RTT+2B/C). Therefore, dependence on RTT not only 
> chokes the TP but also makes it unfair!
> 
> Losses then seem to me as a second order issue, something that TCP has 
> to do to adjust its average window. I suppose with active queue 
> management one could take care of that.
> 
> For the point about correlated packets, the solution looks like putting 
> negative exponentially distributed time-gaps between the departing 
> packets. Just a rough idea.
> 
> Anyways, this is what i think could be fundamentally improved in the 
> protocol. Please do feel expand our understanding, this is after all a 
> discussion group.
> 
> 
> regards,
> SM
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>