From: Dennis Dungs (Dennis.Dungs@freenet.de)
Date: 03/20/04
From: "Dennis Dungs" <Dennis.Dungs@freenet.de> Subject: tcptrace Congestion Control in TCP Date: Sat, 20 Mar 2004 15:17:24 +0100 Message-ID: <000101c40e86$11bcaa00$76030a0a@kom.auc.dk>
Hi,
I have a general question on TCPs congestion control algorithm. I searched
for the answer in different RFCs as well as I read different papers about
the general implementation of TCP and in Linux. I failed to find an answer.
Also a look into the Linux TCP source code did not help.
So I hope to get an answer from the mailing list. If the question is
offtopic, please referr me to a point, where I can find the answer.
As what I understand about TCP, the Tahoe, Reno and NewReno implementation
of TCP use a reactive approach to adapt dynamically to the maximum avialable
bandwidth. Thus, it creates artifically packet loss to detect the maximum
bandwidth. This is done by a linear increase of cwnd per RTT (in congestion
avoidance phase).
Secondly, the receiver can advertise a window (rwnd), that reports the
number of bytes he is willing to accept. The rwnd basically reports the
number of bytes currently free in his receiving buffer.
As I made different measurements with Ethereal and tcptrace, I cannot find
any packet loss over a time of 30 seconds. So it can be concluded, that
rwnd limits the sending rate.
I made measurements over Bluetooth and Wireless LAN, each without any packet
loss, but different throughputs. Each time, different maximum rwnd have been
advertised (BT 17520, WLAN 62780). A TCP receiving buffer of 64kByte was
used for both measurements.
So I have two questions:
- Did I made any errors in my considerations?
- What is the scheme to control the advertised window, since it seems not
only to be related to the free buffer space of the receiver?
It would be kind, if I could get an answer.
Thanks in advance,
Dennis
----------------------------------------------------------------------------
To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
majordomo@tcptrace.org.
This archive was generated by hypermail 2.1.7 : 03/20/04 EST