Reconfiguration Information in TCP Options

[hendrikcech]

Hi,

thanks for providing the LeoCC source code!

In your paper you state the following:

Note that reconfiguration events are probed by user devices behind the satellite terminal. If the probing device is a LeoCC sender, the reconfiguration information is directly fed into the rate control. If the probing device is a LeoCC receiver (e.g., application data goes from a normal server to a satellite user), LeoCC uses eBPF [14] to embed the reconfiguration information into the Options field [1] of TCP ACK headers, which are then transmitted back to the sender and incorporated into its rate control decisions.

I compiled LeoCC and used it with a BBRv3 kernel to run iperf3 in downlink direction (server is sending). Looking at the recorded pcaps, I don't see any header option being set that communicates that a reconfiguration happened even though the dmesg output of the sender shows that reconfigurations were detected.

Scanning your code, I also don't see where eBPF is used to embed the reconfiguration information into the TCP Options field.

Could you please explain how LeoCC is supposed to work on the downlink?

Thanks!

[likie0]

Hi,

If you run LeoCC in dowlink direction in our LeoReplayer, then there's no need for eBPF programs to get the reconfiguration information. Instead, the parameter offset should be passed into the kernel module. A helper script (https://github.com/SpaceNetLab/LeoCC/blob/main/traces/extract_reconfiguration.py) is provided which scans the delay trace files and extracts the timestamp of the first periodic reconfiguration event for each trace. If LeoCC is used in dowlink direction in live network, then eBPF is used to embed the reconfiguration information into the Options field of TCP ACK headers.

For the downlink receiver, one eBPF program hooks into the TC egress path to intercept outgoing TCP traffic. It filters for ACK packets and expand the packet buffer at the network layer. This creates the necessary headroom to inject a custom 0xFD experimental option which contains reconfiguration information. Finally, the program performs a header fix-up—updating the TCP Data Offset, adjusting the IP Total Length, and recomputing the L4 checksum—before transmitting the modified packet. For the downlink sender, another eBPF program parses the incoming TCP headers to find our custom 0xFD option. Once it validates the option kind, it decodes the reconfiguration information from the option payload and informs LeoCC whether a reconfiguration is detected.