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

Reporting Packet Receive Timestamps for MOQ #306

Open
PFpengfeng opened this issue Jan 21, 2025 · 2 comments
Open

Reporting Packet Receive Timestamps for MOQ #306

PFpengfeng opened this issue Jan 21, 2025 · 2 comments

Comments

@PFpengfeng
Copy link

PFpengfeng commented Jan 21, 2025

Currently, BBR is employed as the default congestion control algorithm (CCA) in moq-rs. Other algorithms, such as WebRTC's GCC, may be able to achieve better performance. However, QUIC lacks a mechanism to provide feedback on packet receive timestamps, which is indispensable for GCC. Although [I-D.draft-smith-quic-receive-ts] proposed a solution, it was not adopted. Therefore, could moq implement a mechanism, perhaps through a new control message, to achieve the same objective?

@kixelated
Copy link
Owner

Hey @PFpengfeng

You might be interested in this Quinn fork that implements receiver timestamps and GCC. I haven't tried it yet. Independently for work, I ported the C++ GCC code to Rust: https://docs.rs/goog_cc/0.1.0/goog_cc/

@PFpengfeng
Copy link
Author

PFpengfeng commented Feb 5, 2025

Thanks @kixelated
I will test the Quinn fork. But I'm still confused about the implementation of receiver timestamps. QUIC RFC does not define an ack frame with receiver timestamps. If we do want GCC, a mechanism to report packet receive timestamps is the first step. There are two two solutions:

  • Using ACK frame like[I-D.draft-smith-quic-receive-ts] which means a new extension to standard QUIC.
  • Reporting receiver timestamps by upper layer messages, for example defining a new moq control message. A advantage of this scheme is that we don't need any new extension.

Which solution do you think is better?

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

No branches or pull requests

2 participants