-
Notifications
You must be signed in to change notification settings - Fork 51
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 ooni/probe#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 amount of samplers for each time period. It is also worth noting that I believe the already collected 64 network events are fine to determine throttling, but we cannot know for sure, hence it makes sense to improve our data collection capabilities. The related spec PR is ooni/spec#276. Once this diff is merged, we would still need to do the following: - [ ] update dslx to use this functionality - [ ] land Web Connectivity LTE The latter is fundamental to collect speed samples. We're not doing that with Web Connectivity v0.4. While there, this diff also improves the measurexlite documentation a bit.
- Loading branch information
1 parent
1428fb1
commit 7b88651
Showing
11 changed files
with
547 additions
and
48 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,10 +1,44 @@ | ||
// Package measurexlite contains measurement extensions. | ||
// Package measurexlite contains measurement extensions. This package is named "measurex lite" | ||
// because it implements a lightweight approach compared to a previous package named "measurex". | ||
// | ||
// See docs/design/dd-003-step-by-step.md in the ooni/probe-cli | ||
// repository for the design document. | ||
// [measurexlite] implements the [dd-003-step-by-step.md] design document. The fundamental data type | ||
// is the [*Trace], which saves events in buffered channels. The [NewTrace] constructor creates | ||
// channels with sufficient capacity for tracing all the events we expect to see for a single use | ||
// connection or for a DNS round trip. If you are not draining the channels, the [*Trace] will | ||
// eventually stop collecting events, though. | ||
// | ||
// This implementation features a Trace that saves events in | ||
// buffered channels as proposed by df-003-step-by-step.md. We | ||
// have reasonable default buffers for channels. But, if you | ||
// are not draining them, eventually we stop collecting events. | ||
// As mentioned above, the expectation is that a [*Trace] will only trace a single use connection or | ||
// a DNS round trip. Typically, you create a distinct trace for each TCP-TLS-HTTP or TCP-HTTP or | ||
// QUIC-HTTP or DNS-lookup-with-getaddrinfo or DNS-lookup-with-UDP sequence of operations. There is | ||
// a "trace ID" for each trace, which you provide to [NewTrace]. This ID is copied into the | ||
// "transaction_id" field of the archival network events. Therefore, by using distinct trace IDs | ||
// for distinct operations, you enable [ooni/data] to group related events together. | ||
// | ||
// The [*Trace] features methods that mirror existing [netxlite] methods but implement support for | ||
// collecting network events using the [*Trace]. For example, [*Trace.NewStdlibResolver] is like | ||
// [netxlite.NewStdlibResolver] but the DNS lookups performed with the resolved returned by | ||
// [*Trace.NewStdlibResolver] generate events that you can collect using the [*Trace]. | ||
// | ||
// As mentioned above, internally, the [*Trace] uses buffered channels on which the underlying | ||
// network objects attempt to write when there is an interesting event. As a user of the | ||
// [measurexlite] package, you have methods to extract the events from the [*Trace] channels, | ||
// such as, for example: | ||
// | ||
// - [*Trace.DNSLookupsFromRoundTrip] | ||
// | ||
// - [*Trace.NetworkEvents] | ||
// | ||
// - [*Trace.TCPConnects] | ||
// | ||
// - [*Trace.QUICHandshakes] | ||
// | ||
// - [*Trace.TLSHandshakes] | ||
// | ||
// These methods already return data structures using the archival data format implemented | ||
// by the [model] package and specified in the [ooni/spec] repository. Hence, these structures | ||
// are ready to be added to OONI measurements. | ||
// | ||
// [dd-003-step-by-step.md]: https://github.com/ooni/probe-cli/blob/master/docs/design/dd-003-step-by-step.md | ||
// [ooni/data]: https://github.com/ooni/data | ||
// [ooni/spec]: https://github.com/ooni/spec | ||
package measurexlite |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.