Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Rework TCP/IP stack for embedded IoT devices

Posted: 20 Jun 2014     Print Version  Bookmark and Share

Keywords:communication protocol  stack  TCP/IP  RAM  RS-232 

The advantage of defining smaller network buffers is that more buffers exist that allow TCP (and UDP) to have more protocol exchanges between the two devices. This is ideal for applications where the information exchanged be in smaller packets such as a data logging device sending periodic sensor data.

A disadvantage is that each packet carries less data. For streaming applications, this is less than desirable. HTTP, FTP and other such protocols will not perform well with this configuration model.

Ultimately, if there is insufficient RAM to define a few network buffers, the TCP/IP stack will crawl.

TCP performance
Windowing. TCP has a flow control mechanism called Windowing that is used for Transmit and Receive. A field in the TCP header is used for the Windowing mechanism so that:

The Window field indicates the quantity of information (in terms of bytes) that the recipient is able to accept. This enables TCP to control the flow of data.

Data receiving capacity is related to memory and to the hardware's processing capacity (network buffers).

The maximum size of the window is 65,535B (a 16bit field).

A value of 0 (zero) halts the transmission.

The source host sends a series of bytes to the destination host.

Figure 3: TCP windowing.

Within figure 3, the following occurs:
1. Bytes 1 through 512 have been transmitted (and pushed to the application using the TCP PSH flag) and have been acknowledged by the destination host.
2. The window is 2,048B long.
3. Bytes 513 through 1,536 have been transmitted but have not been acknowledged.
4. Bytes 1,537 through 2,560 can be transmitted immediately.
5. Once an acknowledgement is received for bytes 513 through 1,536, the window will move 1,024B to the right, and bytes 2,561 through 3,584 may then be sent.

On an embedded device, the window size should be configured in terms of the network buffers available. For example, with an embedded device that has eight network buffers with an MSS of 1460, let's reserve 4 buffers for transmission and 4 buffers for reception. Transmit and receive window sizes will be 4 times 1460 (4 * 1460 = 5840B).

On every packet receive, TCP decreases the Receive Window size by 1460 and advertise the newly calculated Receive Window Size to the transmitting device. Once the stack has processed the packet, the Receive Window Size will be increased by 1460, the network buffer will be released and the Receive Window Size will be advertised with the next packet transmitted.

Typically, the network can transport packets faster than the embedded target can process them. If the Receiving device has received four packets without being able to process them, the Receive Window Size will be decreased to zero. A zero Receive Window Size advertised to the Transmitting device tells that device to stop transmitting until the Receiving device is able to process and free at least one network buffer. On the transmit side, the stack will stop if network buffers are not available. Depending how the stack is designed/configured, the transmitting function will retry, time-out or exit (Blocking/Non-blocking sockets).

UDP does not have such a mechanism. If there are insufficient network buffers to receive the transmitted data, packets are dropped. The Application needs to handle these situations.

TCP connection bandwidth product
The number of TCP segments being received/transmitted by a host has an approximate upper bound equal to the TCP window sizes (in packets) multiplied by the number of TCP connections:

Tot # TCP Pkts ~= Tot # TCP Conns * TCP Conn Win Sizes

This is the TCP connection bandwidth product.

The number of internal NIC packet buffers/channels limits the target host's overall packet bandwidth. Coupled with the fact that most targets are slower consumers, data being received by the target by a faster producer will consume most or all NIC packet buffers/channels & thereby drop some packets. However, even if/when performance/throughput is exceptionally low; TCP connections should still be able to transfer data via re-transmission.

Windowing with multiple sockets
The given Windowing example assumes that the embedded device has one socket (one logical connection) with a foreign host. Imagine a system where multiple parallel connections are required.

The discussion above can be applied to each socket. With proper application code, the connection throughput is a divisor of the total connection bandwidth. This means that the TCP/IP stack configured Window size needs to take into consideration the maximum number of sockets running at any point in time.

 First Page Previous Page 1 • 2 • 3 Next Page Last Page

Comment on "Rework TCP/IP stack for embedded IoT..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top