TCP window flow control issue

TCP/IP Chip W5500
1

Hello WIZNet Community:
We are using the WIZ550io SPI <-> Ethernet module interfacing with the NetBurner™ MOD5541X module. Pretty much successfully implemented and working nicely - mostly…

The WIZ550io is set up as a server to interface with a laptop as a diagostic tool for our system. A main function is to download, from the NetNurner to the laptop up to megabytes of data, in 2000 byte blocks. Wireshark shows the following interchange for transaction of one block:
WIZ550io (Server): Laptop (Client)

  1.                                                 <-------                Request for next packet [PSH, ACK]  Len = 2
  2. [ACK] --------> Len = 0
  3. [TCP Window Update] --------> Len = 0
  4. 1st data segment [PSH, ACK] ------> Len = 1460
  5. 2nd data segment [PSH, ACK] ------> Len = 546
  6.                                                 <--------              [ACK]                                                        Len = 0

  7.                                                 <-------                Request for next packet [PSH, ACK]  Len = 2 ....

So the problem is the [TCP Window Update], which supposedly serves to negotiate the “window size” field. Not at all sure why this is even there.

So fIrst, when we do an analysis (via Wireshark) of the SAME FUNCTION, but via one of the NetBurner Ethernet ports, we do NOT see any [TCP Window Update] msgs. Interesting. Normally, however, this additional msg from WIZ550io does NOT seem to impeded the data downloads.

HOWEVER, occasionally, what we see is a ONE SECOND time interval between the [ACK] (msg 3) ) from the WIZ550io and the transmission of the [TCP Window Update] (msg 4) )!! and this occurs at EVERY sequence, as shown above. So for 10 MB of data, at 2K/second… do the math, and we’re looking at more than an hour!

So this is a problem.

IS there a quick & easy way to tell WIZ550io to NOT try to do any window size negotiation - i.e., just eliminate the sending [TCP Window Update] Messages entirely? That would be the simplest solution.

Thanks for any help or insight.

Ron (in Pittsburgh Strong)

2

Hello,

[TCP Window Update] Packet is a packet sent because the PC’s Window Size is not enough.
If the PC has sufficient Window Size, the W5500 will not send a [TCP Window Update] packet.
So I think that the W5500 sends data without the [TCP Window Update] message, the PC will not receive it and the W5500 will retransmit the data
Anyway, there is no way to disable the [TCP Window Update] packet from being sent.
Thank you

3

Hello Ms. Jeong, and thank you for your quick reply to my question on the WIZnet forum.

Let me explain the situation and our information more clearly.

First, normally, a TCP receiver (in this case, the WIZnet W5500) sends the [TCP Window Update] message to inform the sender that it now has enough buffer space to receive the next message. The previous message sent to the WIZnet was a 2-byte message, which should not cause any buffer overflow.

If we run this same application directly to the NetNurner Ethernet port, the message traffic is identical except for the sending of the [TCP Window Update] message. If you wish, I can send WireShark captures of both interactions.

Please note that the message traffic is synchronized, that is, the application on the WIZnet side (the sender) does NOT send any data to the receiver (the PC) UNTIL the 2-byte message (meaning send next 2000-byte buffer of data) is received. This directly avoids any overflow of the TCP buffers.

Also, please note that NORMALLY, the additional [TCP Window Update] message does NOT cause a problem in the flow of data.

Our major problem is, that sometimes, the WIZnet W5500 delays the sending of the [TCP Window Update] for 1 second, and it does not start sending the data to the receiver until AFTER the [TCP Window Update] message has been sent. This is a serious problem for us. I can also send WireShark captures of this if you would like.

Can you explain why the W5500 would do this 1-second delay for each transmission of the [TCP Window Update] message, and more importantly, what can we do to make sure this doesn’t happen?

Thank you again for your attention on this issue.

Ronald Lupish

Siemens Mobility, Inc

MO RC-US MM-MMF PRJ CSEN SW

664 Linden Avenue

East Pittsburgh, PA 15112, USA

Tel.: +1 412 702-1133

mailto:ronald.lupish@siemens.com

4

That would be good.

Sounds like you have no-delayed ACK for the socket turned off (disabled). What value socket register Sn_MR is being initialized to?

5

Привет, Евгений, и спасибо за ваш быстрый ответ.

К сожалению, английский язык намного легче для меня, моя способность к русскому языку ограничена и очень плоха. L

And so the rest will be in English…

I am setting the no-delayed ACK bit in S0_MR (I am only using socket 0 for our application.) S0_MR is initialized to 0x21. I will send along the WireShark captures shortly.

Best regards,

Ron

6

Attach them here changing their externaion or packing into ZIP/RAR.