Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(s2n-quic-dc): add map events #2362

Merged
merged 2 commits into from
Oct 31, 2024
Merged

feat(s2n-quic-dc): add map events #2362

merged 2 commits into from
Oct 31, 2024

Conversation

camshaft
Copy link
Contributor

@camshaft camshaft commented Oct 30, 2024

Description of changes:

This change adds a bunch of new events to the dc map implementation. These events should provide the following:

  • Knowing when a map was initialized/destroyed
  • Knowing when an entry was requested to perform another handshake
  • Providing insights into secret control packet metrics
  • Knowing when replay protection is being applied and what the current gap is

Call-outs:

There's a few more things I still need to include in a follow-up:

  • Ages of secrets - this can be emitted by the cleaner
  • Cache hit ratios for contains calls

Testing:

I've currently only manually tested that the events are being emitted. As a follow-up PR (since this one is already quite large), I will add several event snapshot tests to show it all working and prevent regressions in events.

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

let key = entry.control_secret();

let Some(packet) = packet.authenticate(&key) else {
self.subscriber().on_stale_key_packet_rejected(
Copy link
Collaborator

Choose a reason for hiding this comment

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

It seems like we ought to have a variant of rejected for failed auth and for just unknown?

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 went back and forth on that. i currently don't have one for unknown - we don't emit anything right now. but probably worth doing.

capacity: usize,

/// The port that the path secret is listening on
control_socket_port: u16,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think we're listening on this port? Or at least we never read from the control socket -- it's purely used for sending. We listen/read control packets from the s2n-quic handshake socket.

It would be nice to have a global counter here for # of maps in existence -- probably this is the right place to emit that counter? (tracked via a global atomic static under the hood)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think we're listening on this port? Or at least we never read from the control socket -- it's purely used for sending. We listen/read control packets from the s2n-quic handshake socket.

Do you think I should just remove it? I guess if we're not listening it's pretty useless.

It would be nice to have a global counter here for # of maps in existence -- probably this is the right place to emit that counter? (tracked via a global atomic static under the hood)

I'm thinking the subscriber would be the one that tracks the number. Usually we try to keep the event emissions decoupled from the aggregation.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah I'd just drop the control socket port.

I'm thinking the subscriber would be the one that tracks the number. Usually we try to keep the event emissions decoupled from the aggregation.

How can the subscriber keep track of a global number? We inherently need a global in the map if we want an actually global number.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Couldn't it just take the difference between the number of init and deinit events?

Copy link
Collaborator

Choose a reason for hiding this comment

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

No, because I might not always configure the subscriber. The goal of the global static is to ensure that if at least one subscriber is used I can get an accurate count.

Maybe there's other ways to achieve that though.

@camshaft camshaft marked this pull request as ready for review October 31, 2024 20:16
@camshaft camshaft merged commit fcdb914 into main Oct 31, 2024
130 checks passed
@camshaft camshaft deleted the camshaft/dc-map-events branch October 31, 2024 21:18
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