TCP Cwnd, Adv window and Window size
newbie123
window in TCP and TCP window size. I was believe that when connection
is first setup the congestion window is how much can be sent in the
first packet. once an ack is recvd than it gets incremented however in
packet capture tool I see window size is mostly always constant even
at start of connection. how can one side say that my window size
(which is how much that host can receiv)is 65535 but in actuality it
can only receive 1 segment size which is the receivers advertised
window. thanks
Rick Jones
The "effective" TCP window size will be the minimum of at least these
four things:
1) the receiver's advertised window - what you see in the window
field, perhaps scaled by the wscale option you might see on the
SYNchronize segments used to establish the connection. generally
related to the value for SO_RCVBUF in a get/setsockopt() call
2) the quantity of data the sending TCP can track for possible
retransmissions - a sending TCP must retain a reference to the data
it sends until it is ACKnowledged by the recieving TCP. this does
not appear in a field in any headers sent on the wire
3) the sending TCP's computed value for the congestion window (cwnd) -
this is the quantity of data (or number of segments) that the
sending TCP reasonably believes can be sent into the network at one
time without triggering congestion and thus packet loss. this does
not appear in a field in any headers sent on the wire.
4) the quantity of data the sending application is willing to send at
one time before it stops and waits for a response from the remote
application.
rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
newbie123
thx for helping. why does it say 65535 in the window field in a
sniffer trace? many documents say that the congestion window will
atmost be 2 or 3 mss which is what is the maximum that can be sent. so
essentially when its configured in the registry that the window size
is 65535 or more it doesn't matter on the initial startup of the tcp
connection. is that correct?
Rob Warnock
+---------------
| why does it say 65535 in the window field in a
| sniffer trace? many documents say that the congestion window will
| atmost be 2 or 3 mss which is what is the maximum that can be sent.
Those must be *old* documents. All reasonable recent TCP stacks
are capable of handling *large* windows (and correspondingly large
amounts of data in flight) -- *megabytes*, even!! -- though you may
have to set a per-connection option to get above the system default.
+---------------
| so essentially when its configured in the registry that the window size
| is 65535 or more it doesn't matter on the initial startup of the tcp
| connection. is that correct?
+---------------
Depending on your operating system, the default *receive* window
[what you're seeing in packet traces] may be significantly different
from the default *send* buffer space maximum. For example, on one
FreeBSD I have:
$ sysctl net.inet.tcp | grep space
net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 65536
$
whereas on another:
$ sysctl net.inet.tcp | grep space
net.inet.tcp.sendspace: 57600
net.inet.tcp.recvspace: 57600
$
But as noted above, those are just defaults, and may be adjusted
up or down on a per-connection basis with the "setsockopt()" SO_SNDBUF
and SO_RCVBUF options. [I would imagine MS Windows has something similar.]
By the way, the motivation for large send/receive buffer sizes is that you
can't achieve a throughput of B bytes/sec on a connection with T seconds
of round-trip latency unless you have B*T bytes of buffer at both ends
(and advertise B*T bytes of TCP receive window). With today's multi-megabit/s
Internet speeds and global round-trip times up in the 100's of milliseconds
[sometimes even seconds!], that's a lot of buffering needed to get good
performance.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rick Jones
> thx for helping. why does it say 65535 in the window field in a
> sniffer trace?
Does your sniffer trace also include the SYNchronize segments? Some
TCP stacks may follow a simple (perhaps simplistic) heuristic of "when
the window size is configured for > 65535 set the window field to
65535 and pick the "closest" window scaling value to include the
actual window size.
This is why interpreting the TCP window field is, well, difficult,
when one has not also captured the connection establishment...
> many documents say that the congestion window will
> atmost be 2 or 3 mss which is what is the maximum that can be sent.
There are really several "windows" in play in TCP these days, that is
what I was trying to convey before. There is the "classic" TCP
receive window, which is what you see in the packet traces. Since ca
1988 there is also a "congestion" window, which is purely an artifact
of the sending TCP and does not appear in the header. That is the
sending TCP's idea of how much data it can send at one time without
overwhelming the network between him and the receiver.
So, in the context of those two, a sending TCP will send no more than
his computed congestion window, *or* the receivers advertised window,
whicever is _less_
Now, the bits you see about 2 or 3 MSS are likely referring to the
*initial* congestion window. A sending TCP "learns" how much it can
send by, well, "feeling its way" by sending some number of segments,
then as ACKs come back (indicating those segments have left the
network - if they have been ACKed, it means the receiver has received
them which means they are no longer out on the network...) it
increases its idea of how much it can send without triggering
congestion (aka packet loss somewhere between the sender and the
receiver).
At the beginning of the connection, TCP typically has no "history" of
what it has successfully sent to the destination without causing
packet losses. So, TCP has to have an initial congestion window. It
*could* be like Farragut at Mobile Bay and say "Damn the congestion,
full send ahead!" :) and send a full receiver's window's worth of data
at the start of the connection. However, the folks who design the
protocols and heuristics have decided it is better to start with
something less, hence the 2 or 3 MSS initial congestion window.
> so essentially when its configured in the registry that the window
> size is 65535 or more it doesn't matter on the initial startup of
> the tcp connection. is that correct?
Yes.