| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Please let me know if you have any questions about this change.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This CL introduces a new class of packet delay, which may cause packets to be delivered up to 4 seconds late. Do you have appropriate metrics in place to figure out how this will affect delay-based congestion controllers?
(The delay may be exactly the right signal to feed to them, since "no buffer space" is a kind of network congestion .... but it could also be the wrong signal....)
int result_to_record = result;"result" is either a count or a negative error code. You can get this in one line by saying result_to_record = std::min(result, net::OK).
base::UmaHistogramSparse("WebRTC.P2P.UDP.SendRetryResult",Does recording negative values actually work?
Since the tests pass, I assume it does - is this unique to sparse histograms?
histograms.ExpectUniqueSample("WebRTC.P2P.UDP.SendRetryResult", net::OK, 1);Is there a histogram covering Send results? If there is one, should it have recorded one net::OK and one net::ERR_NO_BUFFER_SPACE?
If there isn't one - should there be one?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This CL introduces a new class of packet delay, which may cause packets to be delivered up to 4 seconds late. Do you have appropriate metrics in place to figure out how this will affect delay-based congestion controllers?
(The delay may be exactly the right signal to feed to them, since "no buffer space" is a kind of network congestion .... but it could also be the wrong signal....)
I added another histogram to measure the total delay of the retry attempts. Based on discussions with the Windows Networking team, I expect 4 seconds to be much more than required, but it will be best to verify.
We have customers able to consistently repro in their environments. We're going to work with them to evaluate the fix in Canary and Beta.
Thanks again for the code reviews. I really appreciate it!
"result" is either a count or a negative error code. You can get this in one line by saying result_to_record = std::min(result, net::OK).
Done
base::UmaHistogramSparse("WebRTC.P2P.UDP.SendRetryResult",Does recording negative values actually work?
Since the tests pass, I assume it does - is this unique to sparse histograms?
[According to the function comment](https://source.chromium.org/chromium/chromium/src/+/main:base/metrics/histogram_functions.h;drc=f929a0c3e751200212538123bfb58c0b491c3f62;l=221), sparse histograms support negative values.
```
// For recording sparse histograms.
// The |sample| can be a negative or non-negative number.
```
[CombinedHttpResponseAndNetErrorCode defines the expected values in enums.xml](https://source.chromium.org/chromium/chromium/src/+/main:tools/metrics/histograms/enums.xml;drc=67ccdac9245f9b639376296466f031c86e5c6ef1;l=1883).
Here's another part of Chromium recording net error codes using sparse histograms.
histograms.ExpectUniqueSample("WebRTC.P2P.UDP.SendRetryResult", net::OK, 1);Is there a histogram covering Send results? If there is one, should it have recorded one net::OK and one net::ERR_NO_BUFFER_SPACE?
If there isn't one - should there be one?
Good idea. I added a new histogram: `WebRTC.P2P.UDP.SendResult`.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Approval for p2p. Adding Johannes to approve for the histograms.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
base::UmaHistogramSparse("WebRTC.P2P.UDP.SendResult", result_to_record);How often is this logged? It may be worth using the corresponding histogram macros, if it's logged at a high frequency.
https://source.chromium.org/chromium/chromium/src/+/main:base/metrics/histogram_macros.h;l=407
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
base::UmaHistogramSparse("WebRTC.P2P.UDP.SendResult", result_to_record);How often is this logged? It may be worth using the corresponding histogram macros, if it's logged at a high frequency.
https://source.chromium.org/chromium/chromium/src/+/main:base/metrics/histogram_macros.h;l=407
Thanks for the tips. I updated to use the macro. There's [another UMA in `P2PSocketUdp` that uses the macro](https://source.chromium.org/chromium/chromium/src/+/main:services/network/p2p/socket_udp.cc;drc=329f8536e0668b0189a63c2465fe5a21c1165a91;l=348) for received packets, which suggests we should probably use the macro for recording sent packets.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Adding Adam Rice to review //net/base/net_errors_win.cc. Please take a look when you have a moment
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I think this CL will also have the effect that QUIC will also start retrying sends on WSAENOBUFS errors on Windows. This is probably a good thing, but it is worth explicitly mentioning in the CL description, particularly as that part of the change is not behind a feature flag.
base::RunLoop().RunUntilIdle();It's best not to use `RunUntilIdle()` as it leads to flaky tests. Maybe do
```
base::test::RunUntil([&] {
return histograms.GetBucketCount("WebRTC.P2P.UDP.SendResult", net::OK) == 1;
});
```
?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
I think this CL will also have the effect that QUIC will also start retrying sends on WSAENOBUFS errors on Windows. This is probably a good thing, but it is worth explicitly mentioning in the CL description, particularly as that part of the change is not behind a feature flag.
Great point. I updated the commit message.
It's best not to use `RunUntilIdle()` as it leads to flaky tests. Maybe do
```
base::test::RunUntil([&] {
return histograms.GetBucketCount("WebRTC.P2P.UDP.SendResult", net::OK) == 1;
});
```
?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
8 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: services/network/p2p/socket_udp_unittest.cc
Insertions: 4, Deletions: 10.
The diff is too large to show. Please review the diff.
```
P2PSocketUdp: Retry Send() after ERR_NO_BUFFER_SPACE
Brings QUIC's `ERR_NO_BUFFER_SPACE` retry to `P2PSocketUdp`. See
QuicChromiumPacketWriter::MaybeRetryAfterWriteError() for details:
https://source.chromium.org/chromium/chromium/src/+/main:net/quic/quic_chromium_packet_writer.cc;l=272
In the bug, customers provided logs that show `P2PSocketUdp` failing
with `WSAENOBUFS` on Windows. This change maps `WSAENOBUFS` to
`ERR_NO_BUFFER_SPACE` to match the equivalent POSIX error `ENOBUFS`.
This new error mapping enables the QUIC retry on Windows.
The rest of the change updates `P2PSocketUdp::DoSend()` to retry after
the socket returns `ERR_NO_BUFFER_SPACE`. The retry is on a timer that
starts at 1 millisecond. The timer interval doubles for each retry up to
12 attempts for a total of 4095 milliseconds. The change treats retries
like an async send operation by setting `send_pending_` to true while
waiting for the retry timer.
For diagnostics, this change adds a new log statement and histogram to
determine the effectiveness of the retry.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |