Dar Scott wrote:
On May 31, 2005, at 12:43 PM, Mark Wieder wrote:
I'd also think twice about increasing the size of the TCP transmit
window in any case. The receive window should be fine, but to my
caffeine-deprived brain this morning I think increasing the TCP
transmit window without a corresponding increase in the receive window
at the receiving end could result in an overall slower speed.
Well, I have had my caffeine, so I have no excuse, but I don't know
what transmit window is.
The TCP window is controlled by the receiver.
Not entirely. The "Window" field in the TCP header is indeed the
receiver's definition of the number of octets he is willing to receive,
so he does control it; however, a TCP stack will keep track of the "send
window" for each connection. The "recv window" as sent by the receiver
is an upper bound on the "send window" - but but the send window will be
decreased according to any data sent since the last ACK was received,
and also as a result of NAKs (and slow start). (see rfc 793, sect 3.2)
Also, it will never exceed the configured send window size; thus even if
a remote receiver is able and willing to have the window grow to say
64K, if the inet.sendspace was set to 32K, then the transmitter will
never grow his send window above 32k (because he needs to buffer all
that data within the TCp stack to allow for retransmits, and is
unwilling to hold more than 32k).
Is the "transmit window" the initial congestion window used by some
implementations for slow start? I don't think TCP implementations
increase the congestion window beyond the TCP window.
Am I too focused on the TCP standard and am missing the real world
implementations?
There have been TCP implementations that ignored (or at least violated)
the receive window. For a while this was a favourite way to win
benchmarks, held under controlled conditions where the congestion
control was never triggered - and the ability to get more in-flight data
was an advantage.
But I think the main issue is that the sender can configure his maximum
send window, and this can be lower than the remote system indicates he
is willing to receive.
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.3.0 - Release Date: 30/05/2005
_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution
