Zero bandwidth in trace causes `BwReplayCell` to panic

[Centaurus99]

When a zero bandwidth value appears in the trace, the change_ratio in this block of code evaluates to inf (infinity).

rattan/rattan-core/src/cells/bandwidth/mod.rs

Lines 567 to 579 in 390c796

	let Some(change_ratio) =
	last_bandwidth.map(|last| last.as_gbps_f64() / bandwidth.as_gbps_f64())
	else {
	// If the last_bandwidth is unknown, nothing to adjust.
	return;
	};
	let (new_logical_transmission_start, next_available) = calculate_bw_change(
	transmitting_packet.get_timestamp(),
	self.next_available,
	change_time,
	change_ratio,
	);

This results in a panic inside calculate_bw_change when Duration is multiplied by the inf change_ratio.

rattan/rattan-core/src/cells/bandwidth/mod.rs

Lines 151 to 166 in 390c796

	fn calculate_bw_change(
	logical_start_transmission_at: Instant,
	scheduled_to_send_at: Instant,
	change_time: Instant,
	change_ratio: f64,
	) -> (Instant, Instant) {
	// Fraction already transmitted, rescaled to the new bandwidth
	let sent_time = change_time
	.duration_since(logical_start_transmission_at)
	.mul_f64(change_ratio);
	// Remaining transmission time, rescaled to the new bandwidth
	let unsent_time = scheduled_to_send_at
	.duration_since(change_time)
	.mul_f64(change_ratio);
	(change_time - sent_time, change_time + unsent_time)
	}

Panic Message:

thread 'tokio-rt-worker' (2336485) panicked at /rustc/01f6ddf7588f42ae2d7eb0a2f21d44e8e96674cf/library/core/src/time.rs:965:23:
cannot convert float seconds to Duration: value is either too big or NaN
stack backtrace:
   0: __rustc::rust_begin_unwind
             at /rustc/01f6ddf7588f42ae2d7eb0a2f21d44e8e96674cf/library/std/src/panicking.rs:689:5
   1: core::panicking::panic_fmt
             at /rustc/01f6ddf7588f42ae2d7eb0a2f21d44e8e96674cf/library/core/src/panicking.rs:80:14
   2: core::time::Duration::from_secs_f64
             at /rustc/01f6ddf7588f42ae2d7eb0a2f21d44e8e96674cf/library/core/src/time.rs:965:23
   3: core::time::Duration::mul_f64
             at /rustc/01f6ddf7588f42ae2d7eb0a2f21d44e8e96674cf/library/core/src/time.rs:1024:9
   4: rattan_core::cells::bandwidth::calculate_bw_change
             at /home/runner/work/rattan/rattan/rattan-core/src/cells/bandwidth/mod.rs:160:10
   5: rattan_core::cells::bandwidth::BwReplayCellEgress<P,Q>::change_bandwidth
             at /home/runner/work/rattan/rattan/rattan-core/src/cells/bandwidth/mod.rs:574:64
   6: rattan_core::cells::bandwidth::BwReplayCellEgress<P,Q>::update_bw
             at /home/runner/work/rattan/rattan/rattan-core/src/cells/bandwidth/mod.rs:619:18
   7: <rattan_core::cells::bandwidth::BwReplayCellEgress<P,Q> as rattan_core::cells::Egress<P>>::dequeue::{{closure}}
             at /home/runner/work/rattan/rattan/rattan-core/src/cells/bandwidth/mod.rs:702:26
   8: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/01f6ddf7588f42ae2d7eb0a2f21d44e8e96674cf/library/core/src/future/future.rs:133:9
   ...

[Lethe10137]

This is confirmed to be a bug.
The root reason is that, after bandwidth cell is refactored with logical timestamp, the logical timestamp of a packet is changed 2 times:

1. Upon "Start Sending", the packet's timestamp is reset to the time that logically the transmission of the packet starts (at the current bandwidth).
2. Upon actually sending the packet (out of the cell), the packet's timestamp is set to the logical time that it leaves the cell.

The 1. here implies a non-zero sending rate, as during possible bandwidth changes, we maintain that

$\text{portion the packet has been transimtted} = \dfrac{\text{Change time} - \text{Old logical start sending}}{\text{packet length} / \text{Old sending rate}} = \dfrac{\text{Change time} - \text{New logical start sending}}{\text{packet length} / \text{New sending rate}}$

There are 2 problems:

1. If the bandwidth is set to 0 (which is the case of the issue when replying a mahimahi trace), there will be a nan.
2. If the bandwidth is changed so low, we may set the "new logical start sending" to somewhere before the epoch of tokio::Instnat ! -- note that the epoch is invisible to user-space, and is typically the start time of the system's monolithic clock ( imprecisely, the boot time of the system).

A simple walk around is that let the bandwidth cell treating any bandwidth below 100bps as 100bps. But a complete solution may need some refactoring.

[BobAnkh]

@Lethe10137 We could have a deep discussion and a complete solution in this repo after our manuscript submission, but we could have any workaround you would like if you have to bypass this bug for any experiment. cc @Centaurus99