Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

tcp windowsize


my question:

i have a cat 6509 which has a GigabitLink to outr mainframe.

over this connection we do storage of our server to our mainframe.

this applikation (adsm) uses tcp.

the server and the host agree on windowsize 65535.

but if the server send 2 tcp-adsm datagrams, (each 1514 bytes big) the host sends an ack - why ??

Is this a parameter in the applikation ?

why do the both not use the whole windowsize ??

(i want to increase the throughput)

thanks for an answer and greetings from austria !


Re: tcp windowsize

Ethernet has a MTU (The MTU is a limit, expressed in bytes, on the size of data sent over a network) of 1500 bytes (1514 if include headers etc). 16Mbs Token ring has an MTU of 17914, FDDI is 4352.

So, the 65535 must get broken up (fragmented) to be able to fit on the ethernet media. Every 2 packets that the mainframe receives he acknowledges so that the server doesn't need to retransmit them (tcp is reliable). If it didn't ack, the server would resend the 2 packets as he thinks the packets are lost/corrupt/etc.

You can't change the mtu of ethernet (or any media), but you can change the size of a tcp window (consult the vendor docs on how and pros and cons).

Hope this helps.


New Member

Re: tcp windowsize


thanks for answer, BUT:

in my opinion the 65535 is on layer4 -

of course - layer 2 (th) must fragment this in 1514 byte pices.

but 65535 divided by 1500 is about 40 frames.

so if the whole windowsize would be used, the server could send about 40 frames, before the mainframe MUST send a ack !

the server knows about the windowsize of 65535, so he only expects a ack after 65535 bytes and not after 2 frames (about 3000 bytes) !

right ??

Re: tcp windowsize

The TCP window is an estimate of the upper bound on the number of segments that will fit in the length of the pipe between sender and receiver. The window size is increased during a TCP transfer until the end-to-end path becomes too full (indicated by a segment being dropped somewhere in the network), then the size is backed off (cut back to half) and then increased slowly again until the limit is reached. This cycle of back-off and slowly rising window size continues throughout the TCP connection. In this way, TCP tries to optimize the transmit window to maximize throughput over the lifetime of the connection. The receiver advertises his maximum window size to give the sender an idea of how much buffer space the receiver has available. This puts a hard limit on size of the window, even if more bandwidth is available in the network.


-Both client and server have to be set up to match.

-I have read that for unix make sure you are moving large files otherwise slowstart will cause slower than expected throughputs and you need to minimize slowstart

New Member

Re: tcp windowsize

This behavior isn't limiting your throughput. TCP has no knowledge of the datalink layer. It could be a high-latency, high-bandwidth SONET over satellite shot where the window is collapsed very quickly. TCP ACKs just as quickly as it can so as to keep the window open (in fact, according to RFC 1122, an ACK can be delayed no more than .5 seconds or after receipt of two full segments - exactly what you are observing). If it waited until the window fully collapsed, it would have a start-stop effect. This is exactly what sliding windows were designed to overcome. Remember that ACKs are like credits being given back. The more quickly they come, the better to keep the window open and the transmitter working.

Also remember that the window size is agreed to, but isn't fixed. If 64 kBytes is agree to, then a receiver starts out at that value and possibly begins to decrement from that value as data starts to arrive in the receive buffer. What is being reported as the receive window by a receiver on one side dictates the size of the trasmit window on the other side. That transmit window, which constantly fluctuating with the value of the reported receive window on the opposite side, is re-credited with ACKs to prevent it from collapsing to zero, thus halting data flow.

CreatePlease login to create content