Full TCPIP for 8Bit Architectures

1
Full TCP/IP for 8-Bit Architectures

• Adam Dunkels
• Swedish Institute of Computer Science
• http//www.sics.se/adam/

2
8-bit microprocessors

• Most microprocessors sold are 8-bit
• Used in various kinds of embedded systems
• Future sensor networking, ubiquitous computing
• Resource limited platforms
• Less than 100 k RAM, code space
• Moore's law smaller, cheaper
• What about communication?

3
Communication for small devices

• Most embedded protocols designed for hard
  real-time in-system communication
• What about Internet communication?
• Smaller IP networks, LANs
• Is it viable to use TCP/IP for these small
  devices?

4
Conventional wisdom

• Conventional wisdom 1
• TCP/IP is very heavy-weight
• Conventional wisdom 2
• Small stack inevitably violate RFC standards
• Main purpose of this work is to refute this
• TCP/IP can be done in 5k of code!

5
Approach

• Two TCP/IP stack implementations
• lwIP (lightweight IP) designed as full scale
  stack, but smaller
• uIP (micro IP) designed as bare-bones stack,
  the minimal subset
• Both designed to be RFC compliant
• Ability to communicate more important than
  communication performance

6
The TCP/IP stack

• IP best-effort packet delivery
• Forwarding, fragmentation and reassembly
• ICMP error reporting
• UDP simple best-effort datagram transport
• TCP connection oriented full-duplex reliable
  byte stream
• Flow control, congestion control, etc.
• The interesting parts are IP and TCP

7
Making it small

• Small
• Code size ROM requirements
• Buffer memory size RAM requirements
• Buffer memory most critical
• Often less RAM than ROM
• Effective memory management needed
• Small systems no protection domains
• Specially designed API for size reduction

8
Application Program Interface

• Traditional BSD socket API
• Application driven, sequential programs
• A lot of interface logic (glue code)
• The lwIP and uIP APIs
• Event driven
• Can be used to build a BSD socket API
• Applications explicitly coded as state machines

9
API (cont.)

• All application execution triggered by stack
  events
• Connection set-up and tear-down
• CONNECTED, CLOSED, ABORTED
• Data communication
• NEWDATA, ACKED, RETRANSMIT (uIP only)
• Periodic polling event

10
Memory and buffer management

• Traditional BSD approach
• Dynamic allocation of fixed size buffers
• Used in lwIP
• uIP approach
• Single dedicated buffer
• Application may choose to copy incoming data
• Application may use buffer for outgoing data
• Data arriving when buffer is in use is queued (by
  hardware)

11
IP implementation

• Fragmentation not needed
• TCP knows link MTU
• Fragment reassembly
• Rarely used, but needed
• Single reassembly buffer
• Bitmap keeps track of received fragments
• Time-out packets with lost fragments

12
TCP implementation

• Sliding window simplifications
• Do not accept out-of-order segments
• Send only single segment at a time
• Let application take part in retransmissions
• Application may choose to buffer or regenerate
• Generation and regeneration can be coupled
• Need to keep
• Congestion control, flow control, MSS option

13
Trade-offs

• Size vs performance (throughput)
• Small buffers
• Simplified TCP window algorithms
• Size vs programming convenience
• Difficult (different) API

14
Code size

• lwIP
• 15 k (TCP 9k) for x86
• 22 k (TCP 14k) for AVR
• uIP
• 5 k for both x86 and AVR
• FreeBSD 4.8 stack (relevant parts) 60 k (TCP 29
  k) for x86
• More features than lwIP and uIP

15
Performance

• Single segment send window poor performance
• Caused by delayed ACKs at receiver

16
Conclusions

• TCP/IP useful even for small systems
• RFC compliant TCP/IP possible even for small
  systems
• Size/performance trade-off
• Size/programming convenience trade-off

17
Thank you!

• More information and source code
• http//www.sics.se/adam/
• Questions?