Re: large tcp window
From: Alun Jones [MSFT] (alunj_at_online.microsoft.com)
Date: 11/10/04
- Next message: Alun Jones [MSFT]: "Re: CAsyncSocket advice"
- Previous message: Arkady Frenkel: "Re: Matching socket ip addresses"
- In reply to: Arkady Frenkel: "Re: large tcp window"
- Next in thread: Alexander Nickolov: "Re: large tcp window"
- Reply: Alexander Nickolov: "Re: large tcp window"
- Reply: Arkady Frenkel: "Re: large tcp window"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 10 Nov 2004 09:38:39 -0800
"Arkady Frenkel" <arkadyf@hotmailxdotxcom> wrote in message
news:OcN5XstxEHA.1188@tk2msftngp13.phx.gbl...
> I didn't mention the size of data sending , btw , but I mean a lot of
> small
> buffers sending. That example ( Stevens/Snader ) of more effective using
> of
> TCP over UDP even in such case where
> on the first glance Nagle have to decrease performance but with TCP
> sliding
> window that not happen and TCP can be more effective than UDP ( even with
> Nagle :) )
The TCP sliding window is old, and is not designed to defeat the Nagle
algorithm, or work around it, or any such nonsense.
Nagle affects packets in precisely the following way:
Whenever new data is queued to be sent, if data previously sent has been
unacknowledged, the new data will not be sent until either:
a) The amount of data buffered is greater than one full segment.
b) An acknowledgement is received for the previously sent data.
Now, TCP sliding windows does not negate the above algorithm, all it does is
to state that the recipient declares how big its buffer is, and if you've
sent that amount of data, you must not send any more until a new window
advertisement tells you that the recipient has more space. There is a very
tenuous relationship between this and ACKs, but it's certainly not one to
one.
I'm advising you to go back and take a second look at what you believe about
the Nagle algorithm. The only way to get around the Nagle algorithm is to
disable it, to use UDP, to send a continuous stream of data, or to
interleave outgoing and incoming data in a synchronised fashion. Sliding
windows are there by default, and as you note, the default window size is
generally going to be 64k - way larger than Nagle cares about (Nagle cares
about data of the order of one MSS and less). If you care about sliding
windows (especially if you care about large scale windows), you're sending
fast enough to avoid Nagle; if you care about Nagle, your sliding window
size may as well be tiny. Sliding windows were a part of TCP since before
the Nagle algorithm or delayed ACK were introduced - it would be silly to
think that they were ignored when designing either algorithm.
Several small sends that build up to one MSS will be sent, because of rule
a). They will be aggregated and sent as one segment, rather than sent
separately. This is a good thing, because instead of sending 40 bytes of
header and one byte of data, you will send 40 bytes of header and about 1500
bytes of data. Bandwidth usage (amount of useful data divided by total
amount of traffic) goes from 2.4% (1 / 41) up to about 97% (1500 / 1540).
On some networks (such as Ethernet), the minimum packet length is larger
than 40 bytes, so the waste induced by a Nagle-challenged app that disables
the Nagle algorithm can be much larger.
> That correct , but 100 mbps net set 64K window ( unless I set different
> size in registry ), without
> calculations :)
Correct - the default window size is calculated without any ability to
measure round-trip time. The figures I quoted are not remotely close to
normal operational values, they were chosen to make the calculation easy.
Alun.
~~~~
- Next message: Alun Jones [MSFT]: "Re: CAsyncSocket advice"
- Previous message: Arkady Frenkel: "Re: Matching socket ip addresses"
- In reply to: Arkady Frenkel: "Re: large tcp window"
- Next in thread: Alexander Nickolov: "Re: large tcp window"
- Reply: Alexander Nickolov: "Re: large tcp window"
- Reply: Arkady Frenkel: "Re: large tcp window"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
