add RED, ARED and PIE

[CepheusC]

Design Choice

RED and Adaptive RED

1. Following the Linux kernel design, Adaptive RED is implemented as a mode of RED and can be enabled through the adaptive field in RedQueueConfig.
2. pkt_tx_time is used to compute the number of "virtual packet departures" during an idle period for average queue length decay: m = idle_time_us / pkt_tx_time. The upper layer computes this from link bandwidth C and average packet size avpkt as pkt_tx_time = avpkt * 8 / C, then passes it down as a fixed config.

PIE

The standard PIE algorithm (RFC 8033) updates the drop probability p at a fixed interval t_update (default 15ms). Rather than spawning a dedicated periodic timer, this implementation drives the update from enqueue() by catching up on all missed update intervals using the packet's logical timestamp. The rationale is threefold:

1. Architectural generality: Our PacketQueue trait defines a generic interface that all AQM algorithms implement. Inserting a timer into PieQueue would require Arc<Mutex<>> synchronization with the caller's task; placing the timer in the upper-layer loop (e.g., BwCell) would couple it to PIE-specific logic and break composability.
2. Logical time semantics: This framework uses packet-embedded logical timestamps (via Packet::get_timestamp()) rather than wall-clock time. Using the packet's timestamp ensures that update_drop_probability() sees the correct time delta regardless of how the simulation is paced relative to real time.
3. Practical equivalence under load: With t_update = 15ms and typical packet inter-arrival times on the order of microseconds, at least one enqueue() call falls within every update interval under load. The while loop in enqueue() replays all missed update_drop_probability() calls in bulk, producing exactly the same state as a timer-driven implementation.

[un-lock-able]

Please also remember to fix warnings from cargo clippy (in github actions) and run cargo fmt after modifications.

[Copilot]

Pull request overview

Adds three Active Queue Management (AQM) queue implementations (RED, Adaptive RED, and PIE) to rattan-core’s bandwidth cell queue module, enabling more realistic congestion signaling behavior than the existing tail/head drop queues.

Changes:

• Introduces new queue implementations: RedQueue, AdaptiveRedQueue, and PieQueue, each with its own config struct and unit tests.
• Exposes the new queues from rattan-core/src/cells/bandwidth/queue/mod.rs so they can be used by the rest of the crate.
• Adds algorithm-specific state tracking (avg queue length / drop probability / burst allowance / rate estimation) and hard-limit enforcement (packet/byte limits).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
rattan-core/src/cells/bandwidth/queue/mod.rs	Registers and re-exports the new AQM queue modules.
rattan-core/src/cells/bandwidth/queue/red.rs	Adds RED queue implementation + tests.
rattan-core/src/cells/bandwidth/queue/ared.rs	Adds Adaptive RED (ARED) implementation + tests.
rattan-core/src/cells/bandwidth/queue/pie.rs	Adds PIE implementation + tests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Lethe10137]

Please refer to #155 about the "logical timestamp". Conceptually these time-based queue should try to avoid calling Instant::now(), but refer to the timestamp of the packets, which is when the packet "should" be here.

[CepheusC]

I have finished modifying the code for RED, Adaptive RED, and PIE, and have strictly aligned the logic with both the RFC specifications and the Linux kernel implementation.

There are currently one remaining point that need confirmation:

1. Copilot noted that the current retain() implementation removes packets but does not update now_bytes. However, I did not find any corresponding now_bytes updates inside retain() in other algorithms such as DropTail. What is retain() supposed to do exactly? Is the current behavior intentional, or should it be modified to update now_bytes as packets are removed?

[BobAnkh]

cc @un-lock-able @Lethe10137 @EwecaBcD Please reply to the remaining questions to confirm the design.

[Lethe10137]

I have finished modifying the code for RED, Adaptive RED, and PIE, and have strictly aligned the logic with both the RFC specifications and the Linux kernel implementation.

There are currently one remaining point that need confirmation:

1. Copilot noted that the current `retain()` implementation removes packets but does not update `now_bytes`. However, I did not find any corresponding `now_bytes` updates inside `retain()` in other algorithms such as DropTail. What is `retain()` supposed to do exactly? Is the current behavior intentional, or should it be modified to update `now_bytes` as packets are removed?

The retain was only used in the TokenBucket , as far as I know
https://github.com/stack-rs/rattan/blame/bb351ee99f83b64cc2c59860925ad926525c9ecf/rattan-core/src/cells/token_bucket/mod.rs#L133-L138

And this was originally introduced by @EwecaBcD .

[Centaurus99]

@CepheusC Please rebase onto the latest main branch so that the changes will only be in rattan-core/src/cells/bandwidth/queue/. Then we'll do another quick review and prepare to merge.

[Centaurus99]

Overall this is a clean, well-tested PR: it compiles cleanly and all RED/PIE unit tests pass. Requesting changes for three defects around the new seed handling and the adaptive-RED update timing.

• configure() ignores a changed seed (the RNG is never re-seeded) in both RED and PIE.
• seed cannot round-trip through serde: seed: 0 is dropped on serialize and reads back as 42.
• Adaptive RED resets its update reference to the arrival time instead of a fixed 500 ms grid, so the adjustment interval drifts and idle gaps are not caught up (Linux sch_red.c uses a fixed periodic timer).

Details inline.

[Centaurus99]

LGTM. @BobAnkh to make the final decision.

[BobAnkh]

Basically, I agree on the implementation. However, several things need to be checked and confirmed:

• Check the difference of the implementation (I assume you implement it according to the RFC) with kernel's. If any, document them.
• For the naming of the fileds in both queue config struct, I don't know if they are the same as what kernel calls them. If they are different, we should also document that (saying what in the kernel that field corresponds to in documentation comments)
• Since, both PIE queue and RED queue have complex configurations (than our normal queues), we should add documentation comments to both Config struct. Besides that, we can also leave some documentation comments, including the outer documentation comments used at the top of a file or module

cc @Centaurus99 Please also supervise on these things.

[BobAnkh]

I'm fine on the docs, and wait for @Centaurus99 to see the difference and squash-merge the PR

The issues raised in this review have been resolved, and the review is now outdated.