[inetstack] Delayed ACK

[carvalhof]

Description

When the Demikernel receives a data packet, Demikernel calls the do_receive function (https://github.com/demikernel/demikernel/blob/dev/src/rust/inetstack/mod.rs#L614) to process it through the network stacks, including TCP (https://github.com/demikernel/demikernel/blob/dev/src/rust/inetstack/protocols/tcp/established/ctrlblk.rs#L385). TCP stack sets should_schedule_ack flag to indicate to ACK the packet.

As the Demikernel implements Delayed ACK, it uses the ack_deadline variable (WatchedValue type) of the ControlBlock structure to signal Delayed ACKs for TCP. This variable is set (to None) at the emit function (https://github.com/demikernel/demikernel/blob/dev/src/rust/inetstack/protocols/tcp/established/ctrlblk.rs#L856) when the TCP stack sends a segment (triggered by a push or by an ACK from the TCP logic).

However, when the Demikernel receives more than one packet at a time (batch.len() > 1), the receive function of the TCP is called more than once (if the packets are TCP, of course). In this case, from the second packet, the ack_deadline variable is not set to None by the emit function (not called), and the TCP stack proceeds to else (https://github.com/demikernel/demikernel/blob/dev/src/rust/inetstack/protocols/tcp/established/ctrlblk.rs#L757), sending an ACK, even if ack_delay_timeout is not elapsed.

How to Reproduce

Steps to reproduce the behavior:

1. Run the Demikernel as a server, using the tcp-ping-pong application, for instance;
2. Use a TCP generator as a client to send TCP packets continuously (e.g., an open-loop generator).

[BrianZill]

@carvalhof, I don't think there is a bug here, so I'm removing the label.

The purpose of the Delayed ACK algorithm in TCP is to avoid sending more packets than needed, specifically by not sending an ACK if an outbound data packet is about to be sent soon -- in this case, TCP should just piggyback the ACK on the data packet (so that only one packet gets sent instead of two).

Ideally, the delayed ACK timer will never actually expire. Instead, the hope is that an outbound data packet will piggyback the ACK on itself before the timer expires. But if too much time has passed without an ACK (0.5 seconds), or too much data has arrived without an ACK (2 MSS), an ACK should be sent (see RFC 9293 Section 3.8.6.3.) The latter requirement is typically implemented as "ACK at least every other packet", which is what the code at the end of the receive() function does. In other words, our current behavior is the desired behavior.

Note that delaying the ACK in the hopes of a piggyback opportunity is merely an optimization (implementing Delayed ACKs in TCP is a SHOULD, not a MUST, in IETF speak). Moreover, sending an ACK is always okay, as far as TCP is concerned. So, for there to be a bug here, we'd have to withhold an ACK for more than 1/2 a second. Sending sooner is fine.

If you're happy with this explanation, please close this Issue. If you're not, please post additional questions to this Issue.