OpenTCP TCP window and Buffer Size

[samiran_cj]

Im not sure how to adjust the "TCP window" buffer size. It seems that TCP_DEF_MTU macro is the most likely #define to adjust to be a larger window size, but not successful.

Ive configured the BUFMAP to the maximum receive and transmit buffers size and according to the docs it should give me a window size of 1536, but im still stuck at 512 byte.

I feel im missing something simple. Is there an auxilary buffer whose max MTU size is fixed at 512? How does the receive mechanism work.

[mjbcswitzerland]

Hi

TCP_DEF_MTU is sent in each TCP frame to signal the size of the receivers open window. Being a fixed value it will allow the other end to send TCP data until the windows closes - which it will never actually do. When this value is set to a larger value then, the other side can send larger packets but it doesn' mean that it will - it may also be limited during transmission to another value MSS (maximum segment size) which is an option during the connection handshake (SYN).

OpenTCP doesn't support the MSS option nor Windowing as such. Perhaps the segment size if being limited somewhere else in the network or simply by the application at the other end being too slow to collect a larger buffer full of data before it wants to send the next segment - so never utilising the available segment/window size capability.

If you capture a sequence using Ethereal and send it to my Email address I can maybe tell you exactly what is happening.

You may also like to look at the uTasker Operating system with integrated tcp/ip stack for the HCS12. See live demo via web cam at http://212.254.22.36:8080 - log on and control a device using Browser at http://212.254.22.36 (user "ADMIN" password "AL6000S")

A demo project is available at:
http://www.mjbc.ch/software/Demo/j8jdwk-ku7/uTaskerPingDemo.zip
which allows a simulated NE64 to run on the PC in real-time; inclusive Ethernet interface. Ping the simulated device from the local PC or another on the network, see the frames pass through the real NE64 interrupt routines, up the stack...etc.

The uTasker is free to educational establishments and for non-commercial use, including free email support.

Regards

Mark Butcher
www.mjbc.ch

[samiran_cj]

Thanks Mark.

That was very lucid. I was hoping when recieve TCP_DEF_MTU window was made larger the packets would be bigger. Instead the packets crash with a checksum fail dump.

Perhaps I must simply reduce the BUFMAP buffer size since now I know anyway that larger packets dont necessarily come in due to the inter-mediate network elements and I can happily utilize those extra precious Kb of RAM.

[mjbcswitzerland]

Hi

I assume that you are using the NE64 with 8k SRAM. It's a great little device for a number of interesting jobs. (with extended memory the Ethernet interface only works at 10M and so I have stuck with the 80 pin part until now)

However the 8k SRAM also means that it requires tight utilisation of resources. For more powerful jobs the Coldfire is the best choice - the NE64 still remains the best choice for all others 'small' applications.

I tend to keep with small buffer sizes so as to get the most out of the application. This is at the expense of IP efficiency but this is often not a killer. If you want to get data from a remote sensor it is often not a big deal if it arrives chopped up into smaller frames rather than less frames of maximum size - it is still good to be able to get if over the Internet from a single chip and quite power consumption device.

TCP applications are no problem in this respect. Only DHCP is a bit of a nuicance since it requires 1k buffers to be used to ensure that the BOOTP UDP frames really fit, sacrificing 1k which the application could well use. Note that although all the rx and tx buffers have to be the same size, it is not necessary to use all of the tx buffer (the amount of it used is under your control) and so I tend to start variables in the middle of it if I know that I will not utilise it all.

If you are doing an application which receives TCP frames to be sent to a lower speed interface (classically the serial interface using XOFF/CTS protocol) then the lack of windowing support in the OpenTCP implementation becomes a problem. The reason is that there is no flow control mechanism across the network and TCP frames will invariably arrive at a rate much faster that the data can be sent over the interface - in this case the window advertised by the tcp stack will tend to equal the window available in the serial output buffer which must close in order to choke the data - if not it will be lost. Reception TCP frames can also be simply ignored (dropped) if there is no room but this results in ugly repetitions and is inefficient due to the repetition timeout delays.

It's interesting stuff and sometimes quite challenging finding the best compromise.

Cheers

Mark Butcher
www.mjbc.ch

[mjbcswitzerland]

Hi

Another small note.

I mentioned the TCP option "Maximum Segment Size" which can be sent on TCP link establishment to inform of the maximum receive segment size which the receive wants to receive. According to RFC793 (TCP), if this is not used then any segment size is allowed.

I was reading in the TCP/IP bible "TCP/IP illustrated - Volume 1 - the protocols" by W. Richard Stevens and noticed that he quotes that "if one end does not receive an MSS option from the other end, a default of 536  is assumed". (576 byte IP datagram incl. IP and TCP headers of each 20 bytes)

Now I don't kow where the "assumes" actually comes from but it is probably a bit implementation dependent - maybe differences for example between Windows and Unix derived types exist.

A Windows PC advertises MSS = 1460 (maximum possible for Ethernet) when TCP is running over a LAN connection.

It is in fact quite easy to add the MSS option to the SYN in the TCP connection (it consists of 4 bytes in the TCP option field) but OpenTCP would require a larger change since it neither allows IP nor TCP options in its basic form. It builds up all frames at fixed buffer offsets directly in the Ethernet Tx buffer space - very efficient in terms of speed and memory usage (as long as you are careful not to overwrite data not yet sent) but tricky if you want to add any option to improve general IP usage....

Regards

Mark Butcher

www.mjbc.ch