Skip to main content

49 posts tagged with "network"

View All Tags

· 2 min read
Marcin Szamotulski

Overview of sprint 83​

High-level overview​

SRV support (Cardano, Mithril)​

We merged ouroboros-network#5018 which adds support for SRV in ouroboros-network. However, we still need to make a decision whether we require that all Cardano SRVs start with _cardano._tcp, or we leave it open for the future. The former would allow us to use SRVs for different applications, e.g. _mithril._tcp for the mithril diffusion. If that would be the case then we'd prepend _cardano._tcp to what we find in the SRV field of a registration certificate, e.g. prepend _cardano._tcp by cardano-node's diffusion, and _mithril._tcp by the mithril diffusion. The other possibility is to extend the registration certificate to include the addresses of mithril nodes.

Mithril​

We started working on a development plan for Mithril diffusion, [ref][mithirl-diffusion] (note that this is a work in progress).

We also have been working on moving network-related code from the cardano-node to the cardano-diffusion library in ouroboros-network. In the future, this will allow us to share parts of it in the Mithril diffusion [ouroboros-newtork#5082].

Documentation​

We improved our CDDL specifications by annotating which codecs require definite / in-definite encoding of lists & maps, see ouroboros-network#5089.

Mux​

Karl Knutsson (CF) has been working on performance improvements in the multiplexer (network-mux library), ouroboros-network#5093.

Server-side performance considerations​

Karl Kntusson (CF) noticed a performance bottleneck in the responder (server) side of the p2p diffusion layer. We've started working on addressing this issue.

Tx-Submission logic​

We continued reviewing/improving the tx-submission PR ouroboros-network#4887.

Pull requests​

In review​

Work in Progress​

Merged​

· 2 min read
Marcin Szamotulski

Overview of sprint 82​

Extensible Ouroboros Diffusion​

We merged the extensible diffusion PR.

This PR will allow us to build mithril diffusion using ouroboros-network, and more generally, it makes it much easier to develop and deploy one's own decentralised applications based on ouroboros-network. This is part of the ouroboros-network-0.20 release, which will be included in cardano-node-10.3.

Ouroboros-Network-0.20​

We released ouroboros-network-0.20 to CHaP. All released changes are listed in [this table][on-0.20]. The most important changes are:

Removal of NonP2P code base​

We merged Removal of NonP2P Network Components PR. This change will be integrated no sooner than cardano-node-10.4. If you're still using In the NonP2P mode, please upgrade to P2P. Initiator-only mode for local root peers (#5020) is available in the pre-release cardano-node-10.2.1 and future releases. See the, to be published, documentation update.

· 2 min read
Marcin Szamotulski

Overview of sprint 80 & sprint 81​

Current workstream​

We decided to hold some PRs in favour of some others to simplify the merging process. Here's a dependency graph for PRs on which we're working on. The Extensible Ouroboros Network Diffusion Stack PR was the largest in our queue.

Fixes which made into the on-going cardano-node-10.2.1​

Previously, we introduced a new IOError handling policy due to a discussion with an SPO to make some scenarios easier to debug. After testing it (the changes never made it into a release), it turned out this could lead to attacks on the system. Thus, we advocate for better monitoring of nodes (e.g. if resources like file descriptors memory are available, the node is making progress) rather than rely on cardano-node to be up and running.

New mux strategy for starting mini-protocols​

Karl Knutsson (CF) implemented a new strategy for starting mini-protocols, StartOnDemandAny. A mini-protocol which is using this strategy will be started as soon as any StartOnDemand (or StartOnDemandAny) mini-protocol receives input from the network. We will use this starting strategy for the keep-alive mini-protocol.

Local-TX-Monitor protocol changes​

A new query was added, which allows the retrieval of all measures/dimensions of the mempool capacity, e.g. byte-size capacity, ledger's execution units for both memory and execution steps, and reference scripts size. See ouroboros-network#4918.

Network Specification Updates​

We made language improvements in the network specification, see ouroboros-network#5044; and some smaller changes/fixes ouroboros-network#5053.

Other minor changes​

· 4 min read
Marcin Szamotulski
Karl Knutsson

Overview of sprint 78 & sprint 79​

Documentation​

We reviewed the technical report. We closed a number of issues, the most important are:

And a few smaller issues:

This was done in the Network Spec Update PR, we also fixed many grammar & spelling errors network-spec: language.

SRV Record Support​

We worked on SRV records support by ouroboros-network, issue #2780, PR 5018. We will merge it after reuasble diffusion.

Quering Network State through Node-to-Client Protocol​

The aim is to make P2P network stake available through the Local State Query Mini-Protocol.

We opened a draft PR, also see the issue, where we mentioned all the branches where the work is progressing. See below for more technical details.

Extensible Ouroboros Network Diffusion Stack​

The work stream reached the review phase. See issue#5016.

Tx-Submission​

The Consensus team agreed to implement needed mempool performance optimisations and is making progress on them. See ouroboros-consensus#1359.

Ouroboros-Network-0.19 Release​

We cut ouroboros-network-0.19 and 0.19.1 releases.

Configuration Changes for Block Propagation Times​

Block propagation times are influenced by the number of TCP round trips required to transmit a block.

In mid-December, we published a post discussing configuration changes to the Linux IP stack. These adjustments involved increasing the initial TCP congestion window to 42 segments and ensuring that the congestion window remained open for idle connections.

IOG applied these changes to four stake pools located in Brazil, South Africa, Dubai, and Japan around December 15th.

The Cardano Foundation manages a standard peer-to-peer (P2P) node in Paris, which operates without manual connections to other Cardano Foundation nodes or IOG nodes. After implementing the configuration changes, we noted a statistically significant improvement in the propagation times for blocks larger than 10 segments (about 14,480 bytes) produced by IOG's pools.

Block Size (bytes)Improvement (ms)
14,480 - 28,960-132 to -78
28,960 - 57,920-197 to -130
>57,920-255 to -176
Block Propagation Times

These results demonstrate that a Stake Pool Operator (SPO) can enhance the propagation times of their own pool's blocks by applying config changes targeting TCP's congestion window.

Low-level summary​

Querying Network State through Node-to-Client Protocol​

In the first interaction, we will make it possible to query the node-to-node state through LocalStateQuery mini-protocol (part of the node-to-client protocol).

data ConnectionManagerState peeraddr = ConnectionManagerState {
    connectionMap                 :: Map (ConnectionId peeraddr) AbstractState,
    -- ^ map of connections, without outbound connections in
    -- `ReservedOutboundSt` state.

    registeredOutboundConnections :: Set peeraddr
    -- ^ set of outbound connections in the `ReserverdOutboundSt` state.
  }
  deriving (Eq, Show)


data InboundState peeraddr = InboundState {
    remoteHotSet  :: !(Set (ConnectionId peeraddr)),
    remoteWarmSet :: !(Set (ConnectionId peeraddr)),
    remoteColdSet :: !(Set (ConnectionId peeraddr)),
    remoteIdleSet :: !(Set (ConnectionId peeraddr))
  }
  deriving (Eq, Show)

data OutboundState peeraddr = OutboundState {
    coldPeers :: Set peeraddr,
    warmPeers :: Set peeraddr,
    hotPeers  :: Set peeraddr
  }
  deriving (Eq, Show)


data NetworkState peeraddr = NetworkState {
    connectionManagerState :: ConnectionManagerState peeraddr,
    inboundGovernorState   :: InboundState peeraddr,
    outboundGovernorState  :: OutboundState peeraddr
  }
  deriving (Eq, Show)

· 2 min read
Marcin Szamotulski

Overview of sprint 77​

Initiator only mode for local roots​

We implemented the initiator-only mode for local roots peers described in ouroboros-network#5020. This feature will be available in cardano-node-10.3 (cardano-node#6055).

One will be able to specify diffusionMode (either InitiatorOnly or IntiatorAndRespoinder, the latter is the default) for all local roots in a given local roots group, e.g.

{ "localRoots":
    [ { "accessPoints":
          [ { "address": "10.0.0.1"
            , "port": 3001
            }
          ]
      , "advertise": false
      , "diffusionMode": "InitiatorOnly"
      , "warmValency": 1
      , "hotValency": 1
      }
    , { "accessPoints":
          [ { "address": "10.0.0.2"
            , "port": 3001
            }
          ]
      , "advertise": true
      , "diffusionMode": "InititiatorAndResponder"
      , "warmValency": 1
      , "hotValency": 1
      }
    ]
, "publicRoots": []
, "useLedgerAfterSlot": -1
}

As part of ouroboros-network#5020 we had to change how connections are identified in the simulated testnet environment. We exposed ConnStateIdSupply through P2P interfaces, which allows us to use a global ConnStateIdSupply for all nodes in the simulation. This way, ConnStateId is unique for each connection in the simulation. See ouroboros-network#5026.

Support systems with multiple IP addresses​

We merged ouroboros-network#5017 which allows to run cardano-node on systems with multiple network interfaces or a single interface with multiple IP addresses.

Reusable diffusion​

We were working on early integration of reusable diffusion work stream with ouroboros-consensus & cardano-node. Reusable diffusion will allow us to support both cardano-node and mithril-node in the future. We are pleased to say that we are running a cardano-node that uses refactored diffusion. See:

Tx-Submission Logic​

We had a discussion with the consensus team (Karl Knutsson CF, Nick Frisby Tweag) on network requirements for tx-mempool. See:

SRV record support​

We continued working on the SRV support, see:

Technical Debt​

We renamed some of the test modules to be more consistent across various network components, see ouroboros-network#5028.