TCP Header Could an expert tell me "how" the "window" value is generated and "what" explicitly it means... Appreciate your help as my reference books don't help and I have not been able to locate a precise definition on the Net. Michael Sutton --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Could an expert tell me "how" the "window" value is generated and "what" explicitly it means...
Appreciate your help as my reference books don't help and I have not been able to locate a precise definition on the Net.
The TCP window is the basically the frequency that you send back ACKs to the sending host. If you are recieving data over a TCP connection (say FTP) and both hosts support window scaling then basically what happens is that each time the client machine sends an ack it adds a little bit to the window size to tell the remote host to not expect ACKs as often, and thus causes transfers to go faster because the sending machine can dump more packets on the wire in between checking that it has an ACK. If your window size is small then basically what happens is that you can possibly end up with under-utilised links (and on a modem that sucks) because the sending machine is waiting for an ACK before it sends the next block. If your using a linux box then you will find the setting for enabling window scaling under /proc/sys/net/ipv4 I think. Window scaling has it's downsides, because in the event of a link that drops, say 1 out of 10000 packets then it will take longer to recover your data, because your window may have grown upwards of 3 megs depending on the transfer rate. Cheers. James Tyson --- Samizdat New Media Solutions --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Aug 07, 2001 at 10:24:11AM +1200, James Tyson wrote: If your using a linux box then you will find the setting for enabling window scaling under /proc/sys/net/ipv4 I think. There is a _lot_ more to it that windows scaling... on a modern stack, if you want to run things where are about 4 paramters you might need to fiddle and about 10 of them you need to understand. I would suggest if someone wants to grok TCP they choose a simpler implemention (ie. read Steven's or something). --cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Thanks I have captured both CodeRed I II variants using my packet analyser and the commonality accross all IP's that have sent both variations of the worm probe is the Win Value of 17520... It seemed strange to me that both variants are generating the same Win Value despite carrying significantly different payloads... Each probe is actually ~13 packets 7 are inbound and only one is shown in the Web Logs.. yet I received over 13,000 probes from different IP addresses (unless the client address is spoofed) which is possible. Is 17520 a common value ? Does the OS set this or the program ? Best regards Michael Sutton www.awacs.co.nz --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Aug 07, 2001 at 10:56:46AM +1200, Mike Sutton [ awacs ] wrote: Is 17520 a common value ? Depends Does the OS set this or the program ? Depends. The OS sets this, because the OS constructs the packets, but to what value the OS sets this to is decided by the machanics of the underlying TCP implementation _AND_ also the application. For all the the simpest cases, this interaction is far from straightforward. In a simple case, the OS will alloc n-bytes for receiving to a tcp session (ignore sending for now), it will advertise this as the window... if the application doesn't read data, ACKs will contain smaller and smaller window sizes until it hits zero. Now, the OS might now advertise all of the memory it has reserved, and the application can fiddle this, and there are other things like window-scaling which mean the value your looking at might not really represent anything meaningful at the application layer. That fact theat worm packets have this value has nothing to do with the worm perse (probably not, I don't think it frobs the send/recv buffers), but more to do with the TCP implementation used. --cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Aug 07, 2001 at 10:11:02AM +1200, Mike Sutton [ awacs ] wrote: Could an expert tell me "how" the "window" value is generated and "what" explicitly it means... Appreciate your help as my reference books don't help and I have not been able to locate a precise definition on the Net. Very roughly (it for want more specific details ask off the list, it gets rather complex) the current window is how much data you can send before receiving and ACKnowledgement from the other end. --cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, 7 Aug 2001, Mike Sutton [ awacs ] wrote:
TCP Header
Could an expert tell me "how" the "window" value is generated and "what" explicitly it means...
This is probably hopelessly off-topic (and I'm no expert!), but here goes: The TCP Window field in the header is the amount of data that you can send without receiving an acknowledgement from the other end of the connection. Think of it as the amount of data that's allowed to be "outstanding" (i.e. waiting for an acknowledgement) before you have to stop and wait for an acknowledgement for at least some of it. Originally, TCP had a 16 bit value to describe the window size (up to 64Kb window size), but later enhancement added a "window scaling" option which allows the negotiation of much larger window values. How this value is "set" varies between operating systems. Supported options (e.g. sliding window) are normally negotiated at connection time, and further adjustments (e.g. window size) take place over the life of the connection (successful transmission generally pushes the window size up). Detailed info on tuning specific operating systems is at http://www.psc.edu/networking/perf_tune.html. If you're writing your own sockets code, most operating systems calculate the maximum buffer size as a function of the socket send and receive buffer sizes. There are some exceptions to this, however -- linux is typically perverse, and some Windows-flavoured things lack bits to twiddle. The purpose of all of this, in case you're still wondering, is efficient negotiable rate control (my cluster of Alphaservers can't hammer your Windows CE PDA into the ground with a chunk of data larger than your device's entire memory) while still making the most efficient use of the link available. Like much of the IP, this is an elegant mechanism that achieves something very clever by being deceptively simple. We like IP. IP good. Mmmm. Good. <R>< --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Hi.
Could an expert tell me "how" the "window" value is generated and "what" explicitly it means...
In order to achieve reliable transport (TCP) without a window, one would send a packet and then wait for an acknowledgement (ACK) from the receiver. If an ACK didn't arrive, then the packet would have to be resent. Only after a packet had been sent and acknowledged would the next packet be sent. The problem is that if the round trip delay was 250 ms, then throughput for your connection would be about 4 packets per second even across a 155 Mbps link. The problem is obviously waiting for the ACK from the last packet before sending the next one. In order to achieve good performance a sliding window is used. The window allows many packets to be sent before an ACK for the first has been received. Once an ACK has been received another packet can be sent, all the time maintaining a window of yet-to-be-acknowledged packets. The mechanism allows for links to be kept saturated thus achieving maximum throughput. There are a few problems with this. One is that the receiver may not be able to cope with packets as fast as the sender (and the link) can send them. In order to provide for flow control, the receiver tells the sender (in each ACK) how much more data the receiver is willing to take. The window field of the TCP header contains the window size in bytes. With a PC connected to the Internet via a modem, it is unlikely that this advertisement will change much as the PC will usually be able to process the packets as fast as they arrive. Another is congestion. In order to effectively control congestion on the network, the sender takes the advertised window as the maximum window size. The actual window size used by the sender will vary. TCP uses a slow start mechanism where the window size starts at 1 packet and grows by 1 with each packet successfully sent (up to half of the maximum of the window size advertised by the receiver, after which it grows by 1 only when a window full of packets have been successful). If a packet is dropped, then the window size will be cut in half. Even modest amounts of packet loss cause a large decrease in throughput for a connection because the window size is reduced so quickly (and increases much more slowly). The sender's actual window is based on a number of packets, but the total data in the window will not exceed the number of bytes advertised by the receiver. TCP sends an ACK for each packet, but the ACK does not indicate which packet it is for, but rather the last contiguous position. Because of this, TCP must resend a bunch of packets in response to a single lost packet. Not efficient (in terms of network use, but easy and efficient to code). Congestion control assures the window size won't be very big if there is a lot of packet loss, so the rather wasteful resending isn't quite as bad as it might at first seem. The initial advertised window size is generally set by an operating system parameter. If an application (or the OS) is slow in reading the arriving packets, then the advertised window (in subsequent packets) will decrease. The actual window size used by the sender will be at most the advertised size (but will always start at just 1 packet). Congestion (control) does not affect the advertised window, but simply affects the actual window size used by the sender. -Craig --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
participants (5)
-
Chris Wedgwood -
Craig Anderson -
James Tyson -
Mike Sutton [ awacs ] -
Rob Isaac