Transactional TCP/IP Stack Suitable for WCEC Analysis

• Introduction
  • Platform is a highly resource-constrained embedded system with a persistent memory device and hardware that implements a power-failure interrupt (PFI). The system is intermittently powered by some form of locally generated renewable energy, no battery is present because of the environmental hazards. Capacitors are used instead.
  • On these devices, the system must still achieve guaranteed forward-progress. It must never waste any energy by starting some operation which can then not be completed because power runs out before a new stable state is reached.
  • To achieve this, we use worst-case energy-consumption (WCEC) analysis of the software on the device. It is your goal to develop a transactional networking stack (TCP/IP) to which WCEC analysis can be applied.
    • The device must only turn itself off (persisting the applicaton, OS, and network stack state to non-volatile memory) when it has reached a stable state in which it can remain indefinately.
    • The stack has a set of operations (e.g., advance_tcp_window()) that bring the device from one stable state to another. All these operations must have a WCEC that can be statically analyzed in future work.
  • Future work will attempt to prove properties like liveness and forward progress based on your implementation (envisioned using Petri nets). Your stack should be developed with this in mind.
• Background
  • You should already be familiar with low-level programming (e.g., from https://sys.cs.fau.de/lehre/ws23/bs)
  • https://en.wikipedia.org/wiki/Worst-case_execution_time
    • WCEC is has similar restrictions.
  • https://sys.cs.fau.de/research/respect
  • https://www.nt.uni-saarland.de/publications/vogelgesang2024towards/
  • We assume our system has a PFI (interrupt) to inform us about an imminent power failure: https://www4.cs.fau.de/Publications/2021/eichler_21_hicss.pdf
  • Wikipedia > A Simplified TCP State Diagram
• Related Work
  • https://sys.cs.fau.de/extern/person/gerhorst/23-10_respect-vnv-heap/
  • Similar, but not what we want:
    • https://ieeexplore.ieee.org/abstract/document/4404726?casa_token=SkFW9rUJYrEAAAAA:F29GS1lDyWQvMApxEvNHkgrM4R5kpbyAH4vz9b_bqz0duWCdDPgy5ToEKq0UyPwjlgqDkPDu4Ks
    • https://tldp.org/LDP/LG/issue47/stacey.html
• Design
  • To simplify your stack, you must not have a clear separation of the OSI layers in your implementation (e.g., transport, packet, and link layer).
  • To implement your transaction, here’s an example of a few primitives that will be needed. These will be the building blocks for going from one stable state to another. To implement those, there are numerous resources online (linked under implementation).
    • MAC address lockup
      • Prepare ARP request
        • Could also be part of send_arp_request() but putting all the stuff without side effects into a separate primitive will improve the WCEC of the actual send/await-reply transaction.
      • Send ARP request
      • Await ARP reply
      • Process ARP reply
    • Send IP packet, has O(maxPacketSize)
      • Can be split up similarily to the MAC address lookup.
  • Example of stable states and associated transitions for your network stack (per connection). It is part of your work to analyze whether these can be split up further (goal is to reduce the maximum WCEC of the transitions):
    1. closed: Connection closed, initial state
       • To get to ip_ready, three transactions can be used:
         1. Prepare ARP request
         2. Send ARP request and await ARP reply (see below for details)
         3. Process ARP reply
    2. ip_ready: Ready for sending IP packets (MAC address available)
    3. tcp_transfer(TCP window state):
       • Reached after TCP connection setup (handshake done)
         • Challenge: Can the handshake be split up further to improve the WCEC?
       • It is likely best to parameterize this state with the state of the TCP window (send and ACKed bytes, not-yet sendable bytes). Will later be transformed into one/many Petri net places.
       • Repeated TCP send/ack pairs advance the window
         • Use the “Send IP packet” primitive.
       • close() brings us back to the initial state.
  • Waiting for the response must (unfortunately) be included in the transactions to make sure we reach a new stable state in which the device can remain indefinately without secrificing guaranteed forward-progress.
    • Otherwise, we open the door for infinite loops such as
      1. “I have a little energy”
      2. “I send ARP Request”
      3. “I turn myself off, missing the ARP response”
      4. “I have a little energy again, relize I missed the response and resend the ARP Request”
    • For WCEC we assume some maximum network latency (e.g., one second).
    • Forward progress can of course only be guaranteed if we do not have packet loss.
• Implementation
  • Hardware
    • SoC: ESP32-C3 (https://www.espressif.com/en/products/socs/esp32-c3)
    • NVRAM: Adafruit SPI FRAM (https://learn.adafruit.com/adafruit-spi-fram-breakout)
  • Both Zephyr and ESP-IDF use primitives from Espressif’s binary blobs to interface with the network hardware. Thus, the most portable route is to write a network stack that is OS-independent and only uses these interfaces.
    • This should make your network stack (implemented as a library) portable to both Zephyr RTOS and ESP-IDF (based on FreeRTOS).
  • Existing network stacks from which code can be reused:
    • https://git.nt.uni-saarland.de/respect/esp32-wifi-stack
      • This is a prototype the supports UDP.
    • Zephyr Wifi driver that also uses the Espressif binary blobs: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/wifi/esp32/src/esp_wifi_drv.c
      • Zephyr RTOS Supported Boards » RISC-V Boards » ESP32-C3: https://docs.zephyrproject.org/latest/boards/riscv/esp32c3_devkitm/doc/index.html
      • This driver can be used as a reference, but we can not reuse the full Zephyr networking stack because it was not developed with WCEC analysis in mind.
    • https://github.com/espressif/esp-lwip
      • https://en.wikipedia.org/wiki/LwIP
    • https://github.com/cozis/microtcp