i have a problem regarding a slow tcp conenction via a 10Gig connection. the delay there is one way approx. 6msec.
The maximum throuhgput is about 2MByte/sec.
What we see in the trace is:
the receive window from the receiver is 65535 and window scaling is used (factor 2) leading to 128KB receive window
the sender is not able to fill this window. maximum value is 20KB and average 10KB
there are no drops in the connection
behaviour: the sender sends 6-12 packets within 50nanoseconds and than waits 12msec for the acknowledgement. what i don´t understand is why teh sender doesn´t fill the tcp window . in my opinion he could be able to send about 87 packets without acknowledgement (128000/1460 (whereby 1460 is the MSS)).
i understand that this behaviour could occur at the beginning of a connection (slow start) but i expectet that the congestion window increases as long as there aren´t any drops. but this behaviour stays the same all the time (3-4 hours).
the behaviour is: the clients sends 6-12 packets within 50nanoseconds and waits until the sender acknowledges the packets although the receive window of the opposite side is not filled? why doesn´t the sender increase it´s congestion window? operating system is unix.
is there any possibility to check the size of the congestion window on the server?
has anybode any idea? is something wrong in my understanding?
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
It sounds like a possible bug with the sender. Older stacks don't recognize TCP windows scaling, and although I believe they should "see" a scaled RWIN as 64 K, perhaps that option is confusing the sender. You might disabling scaled windows on the receiver.
You might also try later network components on the sender, assuming there are any.
Otherwise, you're into debugging UNIX internal networking operation.
You also might see if you can find any UNIX support forums.
thanks for your answer. this sounds reasonable. but unfortunately there is one fact you didnt know: the sender itself also announces a tcp_window-scaling. so i assume that the sender supports windows-scaling.
nevertheless the unix support forum is a good hint. in any case i´m going with you that there must be any debugging directly on the server.
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 ...