Skip to content

Conversation

@WesleyRosenblum
Copy link
Contributor

Description of changes:

This change moves the detection of whether a packet should be considered lost or not to s2n_quic_core, for use in different contexts.

Call-outs:

There is a little bit of overlap in the tests between the new code and the recovery::Manager, but for now I think its ok to ensure coverage until we have a better idea of how the recovery::Manager will evolve.

Testing:

Added some new tests

Is this a refactor change? If so, how have you proved that the intended behavior hasn't changed? -->

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link
Contributor

@camshaft camshaft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the approach. Very straightforward to reason about the algorithm when it's isolated like this 🙂

//# detection [RFC5681] [RFC6675]. In order to remain similar to TCP,
//# implementations SHOULD NOT use a packet threshold less than 3; see
//# [RFC5681].
pub const K_PACKET_THRESHOLD: u64 = 3;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be worth accepting this an a parameter, since this is just a default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I can do that, the time threshold is already a parameter so it makes sense

largest_acked_packet_number: PacketNumber,
now: Timestamp,
) -> Outcome {
debug_assert!(largest_acked_packet_number >= packet_number);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a message to this so the caller knows what the expectation is?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants