-
Notifications
You must be signed in to change notification settings - Fork 64
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
Conversation
fb64001
to
221d52b
Compare
Codecov Report
@@ 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
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
d925ea0
to
846af2f
Compare
14eb822
to
dce3ab5
Compare
pkg/gcc/acknowledgment.go
Outdated
@@ -0,0 +1,26 @@ | |||
package gcc |
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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()
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, sounds good!
60fe37a
to
6915d55
Compare
Implements a first version of Google Congestion Control as described in https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02
zms := float64(z.Microseconds()) / 1000.0 | ||
|
||
if !k.disableMeasurementUncertaintyUpdates { | ||
alpha := math.Pow((1 - chi), 30.0/(1000.0*5*float64(time.Millisecond))) |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
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:
loss_based_bwe.go
unit tests