This milestone serves the purpose of setting the methodology plan for the rest of the project. The milestone includes reviewing of the suggested methodology and the code that needs to be implemented in order to get the right results. This is the right time to make amendments to the suggested methodology. The project includes several Retrieval Methods and each one of them includes its own technical details. In this milestone we need to dive deep into each of the retrieval methods and surface details that might change performance drastically.

Detailed breakdown of methodology plan

This milestone is the collection of scripts to be used to for the experiment. The purpose of this milestone is to identify whether we have enough detail at the methodology and development level, or if more detail needs to be integrated in the system, whether we will be able to extract the information we need by the final software and results, or if any readjustment needs to be done to the strategy followed. Although results are not expected at this stage, we need to have a clear idea of what results will be collected when the scripts are executed.

Experiment scripts/PoC

These results and the initial development help in order to judge whether we’re on the right track, or if adjustments need to be made. The purpose of this milestone is to identify whether we have enough detail, or if more detail needs to be integrated in the system, whether we will be able to extract the information we need by the final software and results, or if any readjustment needs to be done to the strategy followed.

Initial Results / Proof of Concept

Anyone should be able to reproduce the experiments done by the team. This is especially important for this project, as the dynamics and structure of the IPFS network changes over time and hence, engineering teams, or community members should be able to re-run the experiments in the future. <ol><li>Any code developed for this project should be migrated, or at least linked from the main GH repository: <a href="https://github.com/protocol/network-measurements." rel="noopener noreferrer" target="_blank">https://github.com/protocol/network-measurements.</a></li><li>The code should include detailed documentation/instructions on how to use the developed software, as well as contact details of the team.</li></ol> This milestone is expected before the end of the project and is not expected to be the final software. Updates can be done to the software and documentation after this milestone too. The milestone is needed in order for our team to carefully review the code, the code comments, as well as the HOWTO guide and provide feedback/ask for revisions in case things are not clear.

Reproducible Experiments & Stable Results

We expect a final report that details the main findings which address the Request for Measurements (RFM), the methodology used,&nbsp;as well as any conclusions made and open issues for future investigation. The report is not expected to be long - think of a relatively detailed blogpost. The Final Report should be posted on the GH repository in the designated folder.

Final Report

The IPFS architecture has grown to include several ways to retrieve content, sometimes referred to "content routing subsystems". These include the original go-ipfs approach, but also pinning services, which normally work through a public gateway. The addition of Hydra nodes, which help to keep content (i.e., provider records) alive, but also help with faster retrieval of those records, presents a separate boost to the architecture. We have not yet studied the latency (particularly the Time To First Byte - TTFB) observed by clients using these different content retrieval methods in a systematic way. <h3>Sucess Criteria</h3><ul><li>We have enough results, in the order of hundreds of retrievals for each Retrieval Method, to draw conclusive statements on the latencies observed with each.</li><li>The primary metric of interest is the Time To First Byte (TTFB).</li><li>The experiments and scripts developed as part of this RFM should be easy to re-deploy and re-use.</li></ul> See also: <a href="https://github.com/protocol/network-measurements/blob/master/RFMs.md#rfm-18--ttfb-through-different-architecture-components" rel="noopener noreferrer" target="_blank">https://github.com/protocol/network-measurements/blob/master/RFMs.md#rfm-18--ttfb-through-different-architecture-components</a>

The IPFS architecture has grown to include several ways to retrieve content. We want to experiment and collect results with each one of those methods and have a comparative view of which one performs best.

TTFB through different architecture components

Jump to section:

TTFB through different architecture components

Problem Description

Solution Requirements

Milestones

Other Information