Skip to main content

40 posts tagged with "network"

View All Tags

· 2 min read
Marcin Szamotulski

High-level overview of sprint 65

Karl Knutsson (CF) fixed a bug which prevented a node using bootstrap peers to sync using them, for a more detailed description see ouroboros-network#4899.

Earlier this year we fixed bugs in IOSimPOR which prevent us from using it in ouroboros-network (io-sim#153, io-sim#159); since ouroboros-network#4872 was merged we have a large number of tests that are using IOSimPOR's schedule exploration. In the last sprint we fixed some bugs discovered by IOSimPOR in ouroboros-network:

We continued working on new tx-submission logic: ouroboros-network#3311 as well as on Genesis. The work on Genesis is split in a few PRs which are currently in review process:

High-level overview of sprint 64

Karl Knutsson (CF) modified peer sharing behaviour to not share peers whith which connections failed, see ouroboros-network#4883 for more details.

We fixed inbound governor counters tracer, see ouroboros-network#4885.

· 3 min read
Marcin Szamotulski

High-level overview of sprint 60

Edited on 8th of May: new EGK counters will be included in `cardano-node-8.9.3`, added links to `cardano-node-8.9.3` PR and `ouroboros-network-0.15` release.

Peer-Sharing Improvements

We continued working on improving peer sharing. As part of this work light peer sharing (e.g. including inbound peers to the known set of outbound governor), was restructured. Now, sending more peers than what was requested by the peer-sharing client is a protocol error, and the connection will be terminated; This hasn't been a resource attack vector since we always limited the number of peers taken by the outbound-governor and the number of peers has always been limited by the size of the mux ingress queue reserved for peer-sharing mini-protocol. These changes will be released in cardano-node-8.9.3. See ouroboros-network#4868

We also merged the work on outbound governor counters, which initially started as just an extension for peer-sharing counters but turned into a larger refactorisation. We announced it in the previous report. These changes will be included in 8.9.3. See ouroboros-network#4845, ouroboros-network#4861.

Light peer sharing (inbound peers) refactorisation allowed us to refactor the inbound governor loop: we restructured it so that the internal state is kept pure (and thus not shared with other threads), while the public part is computed incrementally (with good amortised costs and thus leading to good performance) and exposed to other components (e.g. the outbound-governor), see ouroboros-network#4871 (which is built on top of ouroboros-network#4868).

The PR [cardano-nod#5831] integrates ouroboros-network-0.15 with cardano-node-8.9.x branch. All included PRs / issues in ouroboros-network-0.15 are listed here.

Genesis

We implemented the API needed by the consensus layer for Genesis; see ouroboros-network#4815, ouroboros-network#4846.

We continued working on outbound governor changes to support Genesis:

Bootstrap Peers

Karl Knutsson ([CF]) found and fixed some problems related to big-ledger and public root peers. Here's an excerpt from the changelog file:

  • updated the big-ledger retry state in case of an exception;
  • reset public root retry state when transitioning between LedgerStateJudgements;
  • reduced public root retry timer;
  • don't classify a config file with public-root/bootstrap-peers IP addresses only as a DNS error. See ouroboros-network#4867.

Churn

We merged a refactorisation which synchronises churn with the outbound governor, see ouroboros-network#4617.

Minor Improvements

A few other minor improvements were merged:

Testing

We added quickcheck-monoids package and also submitted an upstream patch to QuickCheck to include a version of the standard All / Any monoids, which are helpful when writing more complex properties. We will use quickcheck-monoids until the upstream PR will be released. It will be available from CHaP. See quickcheck#397.

· 4 min read
Marcin Szamotulski

High-level overview of sprint 58 and sprint 59

Releases

We released cardano-node-8.9.1, and we tagged a soon to be released cardano-node-8.9.2 The 8.9.2 release will have a fixed peer sharing support, which we incidentally broke in 8.9.1. We expanded our test suite to cover discovered bugs (see below for more details). Please also see the release tab in our project to see which PRs / issues were included in a given release, the following mapping might also be useful:

  • ouroboros-network-0.13.1.0 -> cardano-node-8.9.1
  • ouroboros-entwork-0.14.0.0 -> cardano-node-8.9.2

Genesis

We continued working on network Genesis support:

  • ouroboros-network#3396 - churn policy for Genesis;
  • ouroboros-network#4813 - outbound governor support for Genesis;
  • support for cardano-cli to write a big ledger peers snapshot to disk and for cardano-node to pass it to ouroboros-network.

As well as a feature required by consensus:

TxSubmission

Only a little progress was made due to one of us being on vacation.

Churn and EKG metrics

While working on ouroboros-network#4815, we addressed technical debt in churn. The PR removes implicit synchronisation (in terms of delays) in favour of explicit synchronisation with the outbound governor. The PR extends EKG counters traced by the node. See below for some graphs.

Documentation

We updated the documentation on peer sharing, see cardano-node-wiki#44.

Low level details

Peer Sharing Testing

We wrote a testing scenario for peer sharing, which simulates a node setup: A -> B <- C, where neither of the nodes B and C have any local roots; they only learn about other nodes through (light) peer sharing. B learns about A and C because they connect to it, while C should learn about A through peer sharing. This test scenario should prevent us from breaking peer sharing in the future in some obvious ways. In the future, we will also work on extending our test suite with peer sharing in mind. See ouroboros-network#4839, ouroboros-network#4841.

EKG / Prometheus Counters

Note that this is in progress, so some things might still change.

We will provide counters for active (also known as hot) peers, established (e.g. hot & warm) peers and known (e.g. hot, warm and cold) peers. This is the same way one specifies targets in the node's configuration. In addition, the three groups are split into five categories:

  • ledger peers
  • big ledger peers
  • local root peers
  • bootstrap peers
  • shared peers

In addition, we also provide a counter for root peers, which counts ledger peers, big ledger peers, local roots and bootstrap peers, which correspond to the root peers target TargetNumberOfRootPeers in the configuration.

We also provide counters for ongoing promotions and demotions.

Ledger peers are affected by TargetNumberOf{Known,Established,Active}Peers and TargetNumberOfRootPeers. The gap between TargetNumberOfRootPeers and TargetNumberOfKnownPeers will be filled either with ledger peers or peers, which the node discovered through peer sharing. Big ledger peers are affected by TargetNumberOf{Known,Established,Active}BigLedgerPeers.

Below are some Grafana graphs from an experimental cardano-node branch:

Deprecation policy

The previous hot, warm / cold EKG counters will also be available, although deprecated after the new ones are released. Sometime in the future they will be removed.

Grafana graphs

The screenshots are from a node, which is configured without any bootstrap peers, which is why all bootstrap metrics are 0. The node is configured with the following targets:

  "TargetNumberOfRootPeers": 60,
"TargetNumberOfKnownPeers": 100,
"TargetNumberOfEstablishedPeers": 40,
"TargetNumberOfActivePeers": 15,
"TargetNumberOfKnownBigLedgerPeers": 15,
"TargetNumberOfEstablishedBigLedgerPeers": 10,
"TargetNumberOfActiveBigLedgerPeers": 5,

and has a small number of local root peers and one peer in its publicRoots configuration.

Active Peers Metrics

P2P relays

Established Peers Metrics

P2P relays

Known Peers Metrics

P2P relays

Churn Metrics

P2P relays

· 2 min read
Marcin Szamotulski

High-level overview of sprint 57

We released cardano-node-8.9.0 (which includes ouroboros-newtork-0.12.0.0). This release contains the following network upgrades:

Soon we will release [cardano-node-8.9.1] (which includes ouroboros-network-0.12.0.0). This release will contain:

  • Peer sharing improvements & fixes. Contributed and tested by Karl Knutsson CF.
  • cardano-ping updates to support NodeToNode_V13 & peer sharing.
  • Some smaller maintenance changes.

The list of network features included in ouroboros-network-0.12.0.0 and ouroboros-network-0.13.0.0 can be found here.

We also continued working on tx-submission, ouroboros-network#3311. Mostly working on the pure internal API for decision-making and testing it with property-based tests. The next step is to get all the information needed to run the decision logic in an efficient way and later write a mini-protocol client which is using the new API and testing it.

We also started working on thing to finalise the Genesis support from the network. We have a PR under review, ouroboros-network#4832. We also started to investigate how to support big ledger peer snapshots. This requires changes in the topology file as well as cardano-node & ouroboros-network to understand the snapshots; and on the other hand creation of such snapshots by cardano-cli.

Low-level summary

This time everything was high-level, 😉.

· 2 min read
Marcin Szamotulski

High-level overview of sprint 56

Cardano-Node, Cardano-API, Cardano-CLI

In the last sprint, the network team was designated to take the Release Engineering Role, as the coming release contains mostly network advances. Armando Santos has been making progress on it. The following packages were published to CHaP:

and other ouroboros-network packages with minor changes. The following packages were also published:

The work on cardano-node is in progress, see cardano-node#5485

We would like to thank Karl Knutsson (CF) for helping us to test the upcoming cardano-node release.

Ouroboros-Network

We continued working on tx-submission, ouroboros-network#3311

We started to execute an idea to put all configuration values used by the diffusion layer Ouroboros.Network.Diffusion.Configuration module. Currently, default values are spread in different repositories (e.g. cardano-node, ouroboros-consensus). See ouroboros-network#4805.

We restored how syncing works in bootstrap mode to get the same performance characteristics, see ouroboros-network#4809, ouroboros-network#4810.

We started working on Outbound-Governor Genesis mode, see ouroboros-network#4813.

Ouroboros-Consensus

We requested to modify how bulk-sync mode works to make it use the same mechanism that the newly added LedgerStateJudgement. See ouroboros-consensus#958.

Low-level summary

We also addressed a minor issue regarding tracing LedgerStateJudgement changes, see ouroboros-network#4816.