ooni / probe-cli / 5411900081
72%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 443
Run time 5s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
5411900081

push

github

web-flow 
feat: lightweight throttling measurements (#1166)

This diff implements a lightweight approach to throttling that takes
advantage of the step-by-step design and should also be suitable to
measure throttling using `dslx` (see
https://github.com/ooni/probe/issues/2493).

Before discussing the approach implemented here, it is important to
point out that:

1. if we're using step-by-step, we're collecting up to 64 network events
for a single network connection;

2. with step-by-step, each trace is bound to a single network connection
or DNS round trip;

3. both Web Connectivity v0.5 and dslx use the step-by-step approach;

4. therefore, for extreme throttling of a single connection, 64 I/O
events are *a lot of events* to observe throttling;

5. additionally, we're currently limited at downloading `1<<19` bytes of
the body, so there is not much room for collecting *lots of data*
anyway;

6. additionally, if we were to collect more bytes, the bottleneck would
become collecting and uploading the HTTP response body to the OONI
backend.

That said, by exploiting the fact that step-by-step means that a trace
is bound to a single network connection, we can add passive atomic
collection of the bytes received by a trace. Because we're dealing with
unconnected UDP sockets, we also need to be careful about accounting the
bytes received from the peer that sent the bytes. To this end, we
maintain a map from the remote endpoint address and protocol to the
number of bytes received. The trace allows one to export the current
map. Because data collection is passive, we can start as late as the
HTTP download and we would still collect correct cumulative data.

We also introduce a new sampler for measuring throttling. The design of
the sampler is similar to the design we're using inside of ndt7. We use
a memoryless ticker to avoid sampling periodically but we clamp the
distribution such that we will typically receive the expected amoun... (continued)

19066 of 26428 relevant lines covered (72.14%)

27.11 hits per line

Jobs
ID Job ID Ran Files Coverage
1 0 - 5411900081.1 0
72.14
 GitHub Action Run
Source Files on build 5411900081
Detailed source file information is not available for this build.