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/gcc] Implement Bandwidth Estimation #71

Merged
merged 1 commit into from
Jan 15, 2022
Merged

[feat/gcc] Implement Bandwidth Estimation #71

merged 1 commit into from
Jan 15, 2022

Conversation

mengelbart
Copy link
Contributor

@mengelbart mengelbart commented Nov 2, 2021

Description

This pull request tracks the implementation progress for bandwidth estimation using Google Congestion Control. It will introduce interfaces that can hopefully be reused by other bandwidth estimators in the future.

Reference issue

Implements the GCC related tasks of #25

TODO:

  • Implement TWCC Feedback adapter
  • Integrate in bwe tests in pion/webrtc
  • Sending Engine (pacer)
  • Implement Loss based bandwidth estimation
    • Calculate loss and update target bitrate
    • loss_based_bwe.go unit tests
  • Implement Delay based bandwidth estimation
    • Pre-filter acknowledgements and aggregate arrival groups
    • Implement arrival-time filter to estimate inter group delay variation
    • Implement over-use-detector using adaptive threshold
    • Implement Rate Control
    • Add measurement uncertainty updates to kalman filter
    • Add outlier filter for non-zero-mean WGN of measurement uncertainty
    • Add over use time threshold
    • Tune parameters (adaptive threshold, ...)
  • (optional/later) Implement RFC8888
  • (optional/later) Implement RFC8888 Feedback adapter

@codecov
Copy link

codecov bot commented Dec 6, 2021

Codecov Report

Merging #71 (c1f02ed) into master (ec82d53) will decrease coverage by 11.26%.
The diff coverage is 49.08%.

❗ Current head c1f02ed differs from pull request most recent head 04c55ce. Consider uploading reports for the commit 04c55ce to get more accurate results
Impacted file tree graph

@@             Coverage Diff             @@
##           master      #71       +/-   ##
===========================================
- Coverage   79.38%   68.12%   -11.27%     
===========================================
  Files          32       51       +19     
  Lines        1528     2453      +925     
===========================================
+ Hits         1213     1671      +458     
- Misses        244      699      +455     
- Partials       71       83       +12     
Flag Coverage Δ
go 68.12% <49.08%> (-11.27%) ⬇️
wasm 66.89% <49.08%> (-10.79%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
pkg/gcc/acknowledgment.go 0.00% <0.00%> (ø)
pkg/gcc/leaky_bucket_pacer.go 0.00% <0.00%> (ø)
pkg/gcc/loss_based_bwe.go 0.00% <0.00%> (ø)
pkg/gcc/noop_pacer.go 0.00% <0.00%> (ø)
pkg/gcc/send_side_bwe.go 0.00% <0.00%> (ø)
pkg/gcc/usage.go 0.00% <0.00%> (ø)
pkg/gcc/delay_based_bwe.go 12.12% <12.12%> (ø)
pkg/gcc/state.go 16.21% <16.21%> (ø)
pkg/gcc/arrival_group.go 41.66% <41.66%> (ø)
pkg/gcc/minmax.go 57.14% <57.14%> (ø)
... and 10 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ec82d53...04c55ce. Read the comment docs.

@mengelbart mengelbart force-pushed the feat/gcc branch 3 times, most recently from d925ea0 to 846af2f Compare December 10, 2021 16:48
@mengelbart mengelbart force-pushed the feat/gcc branch 6 times, most recently from 14eb822 to dce3ab5 Compare January 13, 2022 19:10
@mengelbart mengelbart requested a review from Sean-Der January 13, 2022 19:22
@mengelbart mengelbart marked this pull request as ready for review January 13, 2022 19:22
pkg/cc/interceptor.go Outdated Show resolved Hide resolved
pkg/gcc/state.go Outdated Show resolved Hide resolved
pkg/gcc/send_side_bwe.go Outdated Show resolved Hide resolved
pkg/gcc/loss_based_bwe.go Outdated Show resolved Hide resolved
@@ -0,0 +1,26 @@
package gcc
Copy link
Member

Choose a reason for hiding this comment

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

Do you think we could move this to internal/cc

This seems like something we could share between congestion controllers. Would love to see this directory be dedicated to gcc specific stuff!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I think we could move it out of this package, but I'm not sure what the right place would be, internal/cc would mean that pkg/gcc can basically only be used from this module, right? I think it would be nice to allow using pkg/gcc without interceptors?

Copy link
Member

Choose a reason for hiding this comment

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

Oh yes! pkg/cc maybe?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I think that would work, but currently I use a default BandwidthEstimator in the interceptor, so that would create an import cycle. But maybe there's a better way to set the default estimator without including the package just for that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

*and the default uses gcc.NewSendSideBWE()

Copy link
Member

Choose a reason for hiding this comment

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

We could maybe do twcc for now and fix in the future?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, sounds good!

@Sean-Der Sean-Der force-pushed the feat/gcc branch 6 times, most recently from 60fe37a to 6915d55 Compare January 15, 2022 04:52
Implements a first version of Google Congestion Control as described in
https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02
@Sean-Der Sean-Der merged commit 38296c7 into master Jan 15, 2022
@Sean-Der Sean-Der deleted the feat/gcc branch January 15, 2022 19:09
zms := float64(z.Microseconds()) / 1000.0

if !k.disableMeasurementUncertaintyUpdates {
alpha := math.Pow((1 - chi), 30.0/(1000.0*5*float64(time.Millisecond)))

Choose a reason for hiding this comment

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

@mengelbart
I was not able to get why we use "5*float64(time.Millisecond)"
for f_max in
alpha = (1-chi)^(30/(1000 * f_max)) calculation.
This is important part and has impact on uncertainty calculation. Please help to clue

if a.numDeltas < 2 {
return usageNormal, estimate, a.max
}
t := time.Duration(minInt(a.numDeltas, maxDeltas)) * estimate

Choose a reason for hiding this comment

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

@mengelbart
why do we multiply estimate(m_hat(i)) from Kalman filter by up to 60 ?
I was not able to find this in standard and/or https://c3lab.poliba.it/images/6/65/Gcc-analysis.pdf

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

Successfully merging this pull request may close these issues.

3 participants