Some questions about the PCC in the QUIC framework

[Jsy0220]

I tried to run the implementaton of PCC in the QUIC framework in ns3 and have some questions:

1. In ComputeMonitorDuration fun, is the unit inconsistency? (the unit of the second variable in max fun is second).
2. Is the CalculateUtility2 fun the lagency-based utility function introduced in the NSDI'18 paper? and is the CalculateUtility fun the loss-based utility function? If so, why are they different from the function in the paper?
3. Is the pacing section very important for PCC？I found that the calculation of utility use the actual send rate as the throughput, so if the actual send rate is far more than the pacing rate(target send rate), what effect does it have on the result? In the QUIC framework, if there is no byte in flight, it also can send datas, so the actual send rate is higher than than the target one.

[nathanhjay]

1. I think you're right that there might be some inconsistency here. @meng-tong how does it look to you? I haven't worked with the QUIC portion much.
2. The CalculateUtility2 is (an approximation) of the latency-based function presented in the paper. The derivative with latency w.r.t time was computed using a linear regression for the paper, I think. So that's one difference. I believe some of the constants are scaled, to the units used in the existing PCC codebase, so that can contribute other differences. The rounding to create a "latency inflation threshold" of 2% presented in the paper is also done somewhat hackily, but taken directly from the implementation used in the paper. For any questions of differences, you're welcome to refer to the NSDI-2018 branch of this repo, which contains the exact code used by the authors of the 2018 PCC-Vivace paper. I think @meng-tong may know more here too, since he was an author on that and provided the code for that branch.
3. I expect fairly accurate pacing (say within about 10% of the target rate) to be fairly important, though we haven't purposely investigated cases where pacing differs from the expected target rate. When PCC uses the utility to compute gradients, the trend of pacing is probably more important than exact value, so if PCC increases the rate by 5% to see what effect that will have, it's probably important that the actual sending rate also increase, even if it doesn't exactly match the target rate. In general, I'm wary of cases where the actual sending rate deviates far from the expected sending rate.

[meng-tong]

@Jsy0220 Thanks for your interest in the PCC QUIC implementation.

This repo is not originally for QUIC framework, so there may be some issues to convert it to QUIC framework (such as the unit inconsistency you pointed out). We actually have a dedicated GitHub repo for PCC implementation under QUIC framework (https://github.com/netarch/PCC_QUIC). This dedicated PCC/QUIC repo is the most up-to-date implementation we tried on QUIC. It is based on the sigmoid utility function in the first PCC NSDI'15 paper, with an additional latency term. (You may need to change some header files and FLAG/variable declaration to make it built on google's public available QUIC codebase.)

As answered by @nathanhjay , the NSDI-2018 branch uses the linear regression based utility function we used in our PCC-Vivace paper. The master branch contains some simplification such as the approximate calculation for RTT gradient.

[Jsy0220]

Thank you very much for your reply. I have two more questions:

1. Why does the calculation of the utility use actual send rate, not the target one? In google's public Webrtc module, there is another implementation of PCC. The calculation of the utility in that module uses the target send rate.
2. I have read the code of PCC implementation under QUIC framework (https://github.com/netarch/PCC_QUIC) roughly and found some difference with the PCC-Vivace implementation in this repo:
   (1). The CanSend fun in PCC-Vivace always returns true, but not in PCC, it seems that it can set a congestion limit in implementation of PCC. So should it have a congestion limit in PCC-Vivace, or just control it's pacing rate?
   (2). If I want to get the appropriate implementation of PCC-Vivace in the QUIC framework, do I just need to change the calculation of the utility and add the rate change section based on the PCC implementation under QUIC framework according to this repo？