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