RE: TCP Connection: Send Window

TCP uses a sliding window protocol. The receiver acknowledges the receipt of each packet, but the sender may transmit more packets before each is acknowledged. Packets may arrive out of order or not at all (dropped packets). The sender keeps a sliding window of packets for retransmission. Once a packet is acknowledged, the packet may be removed from the window and another sent and stored in its place. If the network is garbling packets and a lot of retransmissions are occurring, the sender will reduce the size of the window so it isn't so far ahead of the receiver.

See http://en.wikipedia.org/wiki/Sliding_window_protocol

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Sam_L
Sent: Friday, October 18, 2013 4:15 PM
To: Midrange Systems Technical Discussion
Subject: Re: TCP Connection: Send Window

The underlying transport mechanism is IBM Remote Journals. When I was
looking this morning there was a lot of data being moved. The target
machine is 520 running nothing but Mimix. I don't see any issues with
disk or CPU usage, but I will look again tomorrow morning.

So do I deduce that the Window size is kind of like a buffer where TCP
assembles and de-assembles packets? 262144 is 256K and isn't a typical
IP packet 1492 or there about?

Maybe RJ loads up journal records until it gets as close to 256K as it
can, then sends them out? But I'm still not understanding why I'm
seeing 1 transmission per second when heavily loaded.

Appreciate your input. I've stayed as far as possible from
communications as I can for all my career--I'd rather be programming.

Sam

On 10/18/2013 10:37 AM, DrFranken wrote:

If you look on the far system it's receive window will be doing the same
thing. The Send window must match up with the receive window. Much

like

a trucking company can't send a truck with a 53ft trailer to a company
with room for only a 28 footer. Doing so it would be turned away.

So the connection must be quite busy or the receiving system is busy.
Until the data is transferred out of the receive buffer to the
application the space isn't available and if buffer space is filling
then it begins to 'close the window'. It's very wasteful to send data
that gets dumped (and thus must be resent) due to no buffer space (just
like the trucker!) so the window gets lowered to account for that.

Unfortunately in an effort to be efficient sometimes dispatchers don't
call the customer and send the wrong truck. And with TCP sometimes the
TCP receiver tells the sender "Got your data" so the sender can send
more but the sender can't get the data out of the buffer to the
Application in time so the new inbound data gets dropped. This causes
retransmissions. (Other things do too like actual communications errors.)

- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 10/18/2013 6:11 AM, Sam_L wrote:

Looking with NETSTAT, option 3, I see under "Send window information"
that the Maximum size is 262144 and the Current size is somewhat lower,
fluctuating, 252568, 256672, 253936, etc.

The Total retransmissions is going up about 1 per second.

This is a Mimix remote journal over a VPN to a backup site in another
state. The network folk tell me that there is an internet segment.
Right now there is a lot of data being pushed through it.

Most of the time the Current window size is also 262144 and when it is
there are no retransmissions and Mimix doesn't get behind.

The network guys are not clear what a "Send Window" is. Can anyone

offer

any clarification or suggestions?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.