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

[Sireen Habib Malik]

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