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).
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
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.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...