idnits 2.17.00 (12 Aug 2021) /tmp/idnits9747/draft-trossen-rtgwg-impact-of-dlts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (14 February 2022) is 95 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REF' is mentioned on line 120, but not defined == Outdated reference: A later version (-04) exists of draft-farrel-irtf-introduction-to-semantic-routing-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Trossen 3 Internet-Draft D. Guzman 4 Intended status: Informational Huawei Technologies 5 Expires: 18 August 2022 14 February 2022 7 Impact of DLTs on Provider Networks 8 draft-trossen-rtgwg-impact-of-dlts-00 10 Abstract 12 This document discusses the impact of distributed ledger technologies 13 being realized over IP-based provider networks. The focus here lies 14 on the impact that the DLT communication patterns have on efficiency 15 of resource usage in the underlying networks. We provide initial 16 insights into experimental results to quantify this impact in terms 17 of inefficient and wasted communication, aligned along challenges 18 that the DLT realization over IP networks faces. 20 This document is intended to outline this impact but also 21 opportunities for network innovations to improve on the identified 22 impact as well as the overall service quality. While this document 23 does not promote specific solutions that capture those opportunities, 24 it invites the wider community working on DLT and network solutions 25 alike to contribute to the insights in this document to aid future 26 research and development into possible solution concepts and 27 technologies. 29 The findings presented here have first been reported within the 30 similarly titled whitepaper released by the Industry IoT Consortium 31 [IIC_whitepaper]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 18 August 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Main DLT Concepts . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Communication in a DLT . . . . . . . . . . . . . . . . . . . 6 70 4.1. DLT Interactions . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Resulting Communication Patterns . . . . . . . . . . . . 7 72 5. Challenges for Users and Provider Networks . . . . . . . . . 8 73 6. Experimental Insights . . . . . . . . . . . . . . . . . . . . 9 74 6.1. Types of DLT Peers . . . . . . . . . . . . . . . . . . . 10 75 6.2. Communication Waste . . . . . . . . . . . . . . . . . . . 11 76 7. Opportunities for Network Innovations . . . . . . . . . . . . 11 77 8. Relation to IETF/IRTF Efforts . . . . . . . . . . . . . . . . 13 78 9. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 13 79 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 82 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 85 16. Informative References . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 The current routing system was initially designed for a single 91 purpose, namely reachability between end nodes. This capability is 92 utilized in many higher layer technologies in the form of overlays. 93 Distributed Ledger Technologies (DLT) are one such form of overlay 94 with the aim to facilitate communication patterns that allow a 95 distributed consensus among distributed, and generally unknown, 96 participants in the DLT overlay. 98 The realization of a DLT overlay follows that of other well-known 99 examples for distributed computing tasks, such as Torrents [REF], 100 distributed file storage [REF] and others. That is, DLTs forms their 101 own overlay through contributing 'peers' that partake in the DLT. 102 For this, reachability information (in the form of IP addresses) of 103 other DLT peers is centrally maintained (in so-called 'bootstrap 104 nodes') to establish peer-specific pools of peers, within which each 105 peer in turn communicates for the specific purpose of the DLT. DLTs 106 secure the transactions using transport-level methods, being little 107 concerned with the underlying network(s) itself. 109 Continuing on the insights first reported in [IIC_whitepaper], this 110 document sheds light onto the realization of the DLT overlay 111 mechanisms from the perspective of the resulting impact on the 112 utilized provider networks in the form of the actual communication 113 taking place. 115 For this, we outline the communication patterns upon which DLTs rely 116 (Section 4.2) in order to implement the key DLT concepts (Section 3). 117 Based on our insights of those communication patterns, we then 118 identify a number of key challenges (Section 5) through initial 119 experimental results (Section 6) within an example DLT platform 120 (here, Ethereum [REF]). 122 While the quantification of DLT impact serves as an interesting 123 benchmark into the possible costs for operating DLTs, the identified 124 challenges give also rise to possible opportunities for network-level 125 innovations to improve on the situation observed in our experiments, 126 thereby reducing the identified impact on provider network. 127 Section 7 outlines a possible realization of those opportunities 128 through a constraint-based selection of communication relations, 129 utilizing semantic information beyond IP reachability. 131 With this in mind, we position an improved DLT performance as a 132 possible applicability for semantic routing, introduced in more 133 detail in [I-D.farrel-irtf-introduction-to-semantic-routing], while 134 also soliciting other possible realizations of an improved DLT 135 performance through network-level innovations. Moreover, we draw 136 connections with ongoing IETF/IRTF efforts (Section 8), where our 137 insights may provide useful input. 139 Note: This document does not discuss the particular rationale for 140 selecting DLTs in order to realize the intended application purpose. 141 It therefore does not pass comment on the advisability or 142 practicality of using DLTs, nor does it define any technical 143 solutions for reducing the observed provider impact. 145 2. Terminology 147 The following terminology is used throughout the remainder of this 148 draft: 150 Smart contract : distributed state machine over which transactions 151 will be executed and logged. 153 Transaction : cryptographically signed (set of) instruction(s) 154 against a smart contract. 156 Ledger : information on transactions 158 Block : set of verified ledger information 160 Blockchain : concatenated blocks with longest block representing 161 the current consensus of ledger information. 163 Peer : participant in the DLT, with a possible narrower 164 role of client or miner. 166 Client : a DLT peer issuing transactions towards a set of 167 miners. 169 Miner : a DLT peer receiving transactions from miners and 170 performing suitable block operations and exchanges to 171 maintain DLT information. 173 3. Main DLT Concepts 175 There has been ample work, such as [DLT_intro] [DLT_intro2], among 176 others, including in other SDOs such as the IEEE but also within the 177 IRTF/IETF [DINRGref], on defining main DLT concepts; we refer the 178 reader to those references for more details. We focus our brief 179 introduction here on those concepts most important to understand from 180 a communication perspective. 182 The core abstraction used in a DLT is that of a 'transaction', i.e., 183 a cryptographically signed (set of) instruction(s) to modify a state 184 machine, which in turn represents the distributed consensus the DLT 185 is trying to maintain. These transactions are executed within the 186 higher-level concept of a 'smart contract', which implements the 187 specific DLT application, such as for cryptocurrency, storage 188 management, decentralized data governance or others. 190 Valid transactions are maintained in a distributed 'ledger' in the 191 form of hashed information referred to as 'blocks'. Consensus is 192 represented through the longest available 'blockchain' that can be 193 obtained from another DLT peer. 195 The validation of transactions, and therefore the inclusion into the 196 (distributed) ledger, is realized through the consensus layer, 197 realizing computational operations, such as Proof-of-Work, Proof-of- 198 Stake, and others. There has been much discussion on the 199 implications of those computational aspects, e.g., on energy 200 consumption, which is not the focus of this draft. 202 Figure 1 provides an overview of a typical layering within a DLT 203 architecture. The focus of this draft is on the layers below the 204 session, i.e. the communication that needs to be upheld in order to 205 facilitate transactions and block exchange within the DLT system. 207 +------------++---------------------------------------------------------+ 208 | Application|| User | DLT | DLT | DLT |Decentralized| 209 | Layer || Interface | Wallet | Explorer | Analytics | Finance | 210 +------------++---------------------------------------------------------+ 211 |App Protocol|| Identity | Token | Storage | DLT |Decentralized| 212 | Layer || Mgmt | Mgmt | Mgmt | Oracle | Governance | 213 +------------++-----------------------------+---------------------------+ 214 | Contract || Transaction | Smart | 215 | Layer || Engine | Contract | 216 +------------++-----------------------------+---------------------------+ 217 | Consensus || PoW/PoS/DPoS/PBFT/Raft/etc. | 218 | Layer || | 219 +------------++-------------------+------------------+------------------+ 220 | Session || Transaction | Block | Account | 221 | Layer || | | | 222 +------------++-------------------+------------------+------------------+ 223 | Transport || TCP | QUIC | TLS | 224 | Layer || | | | 225 +------------++-------------------+------------------+------------------+ 226 | Network || (DNS + ) IP | Service | Pub/sub | 227 | Layer || | Routing | overlay | 228 +------------++-------------------+------------------+------------------+ 229 | Resource || CPU | Storage | Transport | 230 | Layer || | | Network | 231 +------------++-------------------+------------------+------------------+ 233 Figure 1: DLT Conceptual Architecture [IIC_whitepaper] 235 4. Communication in a DLT 237 With our focus on the communication impact of DLTs, we now tease 238 apart the communication as it usually takes place in a DLT in order 239 to realize the transactions within a distributed ledger and the 240 maintenance of the latter. We first outline the interactions at a 241 higher level before delving into the communication patterns that 242 result from those. 244 4.1. DLT Interactions 246 We can dinstiguish three core interactions in a DLT: 248 1. A client commits a transaction to the DLT. The transaction 249 request is being diffused across a set of DLT miners, which 250 response to the transaction request separately and add the 251 transaction to their internal ledger information. The commit of 252 the transaction leads to the miners committing compute and 253 storage resources in relation to the smart contract that 254 underlies the transaction. For this, so-called 'proofs' will be 255 executed as part of the computational part of the DLT, although 256 some methods for proof require additional communication to take 257 place, e.g., election protocols. 259 2. The result of the aforementioned proof is a 'block' (of ledger 260 information) that the miners in turn commit to a set of (other) 261 DLT miners, which each receiving miner adds to their internal 262 blockchain. 264 3. A client may query the latest blockchain, again from a set of 265 miners to which the query is being sent. The longest returned 266 blockchain represents the most trustworthy ledger information 267 available. 269 We can see from those interactions above that communication in a DLT 270 is multipoint in nature, i.e., transactions or information (such as 271 blocks) are sent to a set of DLT peers, not just a single one. 273 Important here is that the set of DLT peers is a randomized sample 274 from a larger pool of available DLT peers; this is to achieve 275 diffusion among many DLT peers, avoiding repeated communication with 276 a fixed set of DLT peers and thereby reducing the threat of collusion 277 of information through a malicious set of DLT peer. 279 The consequence of that varying random nature of the multipoint 280 diffusion, however, is that repeated unicast replication is utilized 281 instead of efficient network-level multicast; this constitutes a 282 first recognizable impact on provider networks. 284 In the following subsection, we now focus on the communication 285 patterns that are utilized to achieve the aforementioned interaction. 286 Special attention is here given on the establishment of the pool of 287 DLT peers that is used in the multipoint operations that are executes 288 for each interaction, be it a transaction or the commitment of a 289 newfound (ledger) block. 291 4.2. Resulting Communication Patterns 293 As mentioned before, it is key for any DLT peer, be it a client or a 294 miner, to establish and maintain a 'pool of peers' from which it can 295 select a set of DLT peers for each intended interaction. Figure 2 296 outlines those steps, detailed in the following. Our insights on 297 realization were obtained from an Ethereum based experiment, using 298 the go-ethereum release V1.10.2-stable on a Linux-based machine, 299 operating out of Munich, Germany. 301 1. The first phase is that of a 'peer discovery'. For this, an 302 initial list of DLT peer information is obtained from a 303 'bootstrap node', of which only few exist in the DLT, holding the 304 IP address and port information of each DLT peer that has signed 305 up to the DLT overlay (other information may include DLT-specific 306 information, such as an overlay ID or similar). 308 2. This initial list of DLT peers is now contacted through a (UDP- 309 level) PING/PONG sequence, thereby discovering those DLT peers 310 that are reachable for the DLT interactions. 312 3. A successful discovery of the DLT peer is now followed with the 313 establishment of suitable transport security. Once successfully 314 secured, the discovered DLT peer is being added to the 'DLT pool' 315 list at the initiating DLT peer. 317 4. Once security is established, capabilities are exchanged that 318 ensure that the discovered peer can successfully complete 319 possible requests. Those capabilities may include HW 320 capabilities (e.g., GPU usage, certain memory build-out), SW 321 capabilities (use of certain hash functions, blockchain 322 checkpoint) and others. 324 5. The initiating DLT peer repeats now the previous steps 1 through 325 4 until the pool size reaches a defined limit. Unlike contacting 326 the bootstrap nodes, however, the newly and successfully 327 discovered DLT peers in the previous round are contacted instead 328 for obtaining a list of DLT peers. 330 6. Any member of the DLT pool is continuously checked for 331 connectivity through frequent (e.g., TCP-based) HELLO messages. 332 Any failed HELLO transaction leads to removing the DLT peer from 333 the pool and obtaining another DLT peer as replacement. 335 The final size of the pool is a matter of local configuration (in our 336 case about 28k DLT peers, significantly less than the size of the 337 overall DLT network, which was about 500k at the time of the 338 experiment). 340 Also, a DLT client may commence with transactions (to the DLT 341 overlay) already while the pool creation is still ongoing, thereby 342 progressing to the last step in Figure 2 once a suitable set of DLT 343 peers can be obtained from the overall (and possibly still growing) 344 local pool of peers. 346 +-------------------+ if DLT peer connection failed 347 | Obtain list |<--------------------------------------+ 348 | of DLT peers |<--+ | 349 +-------------------+ | if pool size +--------------+--- 350 | Node | | smaller than max | Maintain peer | 351 | discovery | | | connectivity | 352 +-------------------+ | +-----------------+ 353 | Transport | | 354 | security | | 355 +-------------------+ | 356 | Capability +---+ 357 | exchange | 358 +-------------------+ 359 | 360 | add discovered peers to pool of DLT peers 361 \|/ 362 +--------------------------------+ 363 | Obtain set of DLT peers | 364 | from pool of DLT peers | 365 +--------------------------------+ 366 | Transactions | 367 +--------------------------------+ 369 Figure 2: Steps of Communications in a DLT 371 5. Challenges for Users and Provider Networks 373 Considering the observed communication patterns in the previous 374 section, we can identify a number of challenges that need addressing: 376 1. Reachability information is required to interact with other 377 peers. For that, bootstrap nodes maintain IP addresses of all 378 peers (plus port information). As illustrated in Figure 2, new 379 DLT peers need to download and expand suitable reachability 380 information upon joining, either from bootstrap node or via 381 discovered nodes - see Figure 2, , requiring each DLT peer to 382 maintain a pool of peer as active connections. 384 2. Clients know nothing about capabilities of peers to serve 385 requests. In other words, the discovery in Figure 2 merely 386 ensures possible reachability but not necessarily successful 387 communication. As a consequence, the resulting approach, 388 illustrated in Figure 2, is to (1) contact potential peer, (2) 389 wait for connection, (3) inquire capabilities, (4) disconnect if 390 not matching. Here, peers may never reply to connection 391 establishment (step 2), usually resulting in additional latency 392 due to timeouts involved, prolonging therefore the establishment 393 of the pool of peers to communicate with. Such capabilities 394 often reflect the continuous evolution of business models over 395 DLT networks and may be dynamic in nature. For example, the 396 minimum transaction fee may depend on the 'DLT gas price', which 397 is set up at the transaction recipient (miner). 399 3. Peers map sending of transactions onto unicast communication, 400 which negatively impacts efficiency (bandwidth usage) and 401 transaction completion time. Here, the use of group-based 402 multicast approaches is difficult due to the random nature of the 403 set of peers selected for communication in every request 404 exchange, aiming at the diffusion of requests rather than 405 interacting with a stable (but possibly colluding) set of peers. 407 4. DLT peers need to expose their IP address to the DLT system, 408 replicated to the bootstrap nodes, but also other DLT peers by 409 virtue of the discovery process outlined in Figure 2. This may 410 lead to privacy and/or security issues in the form of geo- 411 identifying specific peers, DoS attacks on particular parts of 412 the DLT and others. 414 6. Experimental Insights 416 To shed some more light onto the possible impact on provider 417 networks, stemming from some of the challenges in Section 5, we 418 conducted experiments, using the same setup described in Section 4.2. 419 More details (and suitable graphical representations of our initial 420 results can be found in [IIC_whitepaper]). 422 Here, the goal was to undergo the steps needed to build up the needed 423 pool of DLT peers, after which we sought to synchronize to determine 424 the longest blockchain available in the discovered pool. The 425 resulting geographic spread of the discovered DLT peers included all 426 continents albeit with an expected clustering of nodes North America, 427 Europe, Asia, and Australia, with only few discovered in South 428 America and Africa. 430 6.1. Types of DLT Peers 432 Our first target was to differentiate types of DLT peers that stem 433 from the communication patterns in Figure 2. Specifically, we came 434 to differentiate the following types of DLT peers: 436 1. Non routable peers: This type include all those peers that never 437 positively responded to step 1 of the discovery, i.e. the PING/ 438 PONG to determine reachability. Reasons here may include to be 439 located behind a firewall, being intermittently available (and 440 switched off during the connection attempt), or simply having 441 left the DLT while still remaining in the information pool 442 maintained at the bootstrap nodes. 444 2. Signalling peers: This type includes peers that respond 445 positively to reachability but do not positively succeed in the 446 transport security or capability exchange steps (blockchain 447 checkpoint). 449 3. Dropped data peers: This type of peers successfully complete all 450 discovery steps, thereby end up in the pool of peers, but still 451 do not provide suitable data upon request (here a valid 452 blockchain information). The reasons here could be unavailable 453 information or not completing the transfer of information 454 (blockchain information can be very large, several GBs, so that 455 DLT peers may run out of available BW budget or decide to sever 456 the connection because of switch-off or other reasons during the 457 transfer). While here communication in the DLT does take place, 458 it is not successful in regards to the intended communication, 459 therefore wasted. 461 4. Data peers: This final type of peers successfully completes all 462 steps in Figure 2, i.e. not only the discovery but also the 463 intended transfer of DLT-relevant data. 465 In our experiments, we determined at about 18% of peers are of the 466 last type, i.e. successfully contribute to DLT purposes, while about 467 2% are of the third category, about 12% are non routable peers and 468 about 68% are signalling peers. In other words, almost 80% of all 469 attempted discoveries fails either because of the lack of 470 reachability or mismatching capabilities. 472 6.2. Communication Waste 474 Looking at the bandwidth usage across the different peer types allows 475 for shedding some light on the communication that needs to be carried 476 through the participating provider networks. 478 Given the amount of data for each blockchain synchronization, it is 479 not surprising that, despite forming a mere 18% of peers, the 'data 480 peers' account for about 58% of traffic in the overall system. This 481 is followed by the 'dropped data peers' with about 31.5% (since still 482 much data is sent albeit unsuccessfully). Both non routable and 483 signalling peers account for a total of slightly under 10% of data 484 used. 486 Although the amount of data that is wasted here accounts for 487 (significant) total of about 42%, the data-heavy operation of 488 synchronization large amounts of (blockchain) data is mainly to blame 489 for this; however, the synchronization has to happen for any DLT peer 490 to start operating as a possible DLT miner, so is not avoidable. 492 7. Opportunities for Network Innovations 494 The challenges outlined in Section 5 lead us to outline possible 495 opportunities for network innovations that may address those 496 challenges and reduce the observed impact on provider networks. We 497 stress here that none of the suggested approaches constitute 498 solutions for those opportunities but merely possible starting points 499 beyond which further study is required: 501 1. Addressing model: With the DLT overlay being realized over an IP 502 network, each DLT peer is being addressed via its IP(v4/v6) 503 address. With the discovery step selecting a dedicated DLT peer 504 (through its IP address), the discovery steps (see Figure 2) 505 include dedicated steps to ensure the reachability of the 506 specific DLT peer under discovery. Until reachability can be 507 ensured, traffic (in the form of PING/PONG messages) and latency 508 (through sending those messages, while needing to wait for a 509 timeout in case the DLT peer is not routable) need to occur, 510 despite the DLT peer not being eventally used for communication. 512 * Approaches such as those in [SOI][SarNet2021] may allow for 513 DLT peers to advertise their capability to serve as a miner by 514 using 'service announcements' that expose the capability to 515 serve transaction requests, which each announced DLT peer 516 representing a service instance of the announced mining 517 service. Such native L3 (or L3.5) level service routing 518 capability would therefore remove any of the discovery steps 519 and the maintenance of the dedicated DLT overlay 520 infrastructure. Furthermore, it would remove any visibility 521 of individual DLT peers' reachability information from other 522 miners, until directly communicating with a specific DLT peer 523 (for which the peer's IP address may be used, as suggested in 524 [SarNet2021]). Last but not least, being able to send a 525 request without previously forming a pool of DLT peers (which 526 is smaller than the number of all DLT peers in the overlay) 527 also increases the possible number of DLT peers to communicate 528 with rather than being limited to the peer-specific pool. 530 2. Constraint-based peer selection: Following on the aspect of 531 relying purely on reachability information in the form of IP 532 addresses, the discovery steps in Figure 2 further include a 533 number of capability-dependent selection criteria to finally 534 include a DLT peer in its pool of peers. Specifically, the 535 security and capability exchange may lead to a disconnect from a 536 successfully contacted DLT because of such exchange leading to 537 mismatching capabilities. Furthermore, even after an initial 538 capability exchange being successful, the actual transaction 539 itself may be constrained by capabilities such as available 540 resources (e.g., bandwidth or CPU), leading to unsuccessful 541 communication, which in turn will need to be compensated with 542 including another DLT peer into the diffusion request. 544 * Approaches such as [SarNet2021] may allow to constrain the 545 forwarding to one of possible many DLT peers. Hence, the 546 capabilities used in the current DLT steps Figure 2 could be 547 encoded as suitable constraints for such selection, the 548 constraints itself being advertised as part of the service 549 announcement (see above). As a result, the request will be 550 forwarded to those destinations only which have previously 551 announced constraints that match those of the request, thereby 552 ensuring the successful completion of the request - further 553 study is needed for those situations in which constraints may 554 change frequently, thereby leading to successful matching, yet 555 still unsuccessful request completion. 557 3. Diffusion multicast: The multipoint replication of the 558 transaction request to a set of DLT peers, chosen from the larger 559 DLT pool maintained at the initiating DLT peer, increases the 560 overall system but, in particular, individual client bandwidth 561 usage, which in turn impacts the provider network by needing to 562 provide the necessary resources for the replicated sending. 564 * Approaches such as those in [SOI][SarNet2021] may allow for 565 sending a service request to a given number of DLT peers, 566 where the replication is part of the constraint-based 567 forwarding decision, thereby optimizing the packet delivery 568 through in-network instead of endpoint-based replication. The 569 challenge here lies in preserving the diffusion character of 570 the multipoint operation. In other words, the set of DLT 571 peers used for the transactions changes for each request with 572 a randomization that attempts to prevent possible collusion 573 through DLT peers. With that, typical group-based methods, 574 most notably IP multicast, do not suffice. 576 8. Relation to IETF/IRTF Efforts 578 Both, DLTs as well as routing innovations, are subject to 579 investigation in a number of related IETF and IRTF efforts. For 580 instance, the Decentralized Internet Infrastructure RG [DINRGref] has 581 been studying various aspects of DLTs and blockchains. Our findings 582 in this draft may provide additional input into the work of this RG, 583 while we would solicit feedback from this group of experts into the 584 specific insights we have derived so far. 586 Furthermore, routing innovations under the label of 'semantic 587 routing' have been the topic of recent work, see 588 [I-D.farrel-irtf-introduction-to-semantic-routing] for an overview. 589 With the examples of service routing as possible approaches to 590 realize the opportunities outlined in the previous subsection, a 591 stronger linkage to this activity should be considered. 593 9. Open Questions 595 The work initially presented in [IIC_whitepaper] focussed on the 596 specific impact that DLT operations may have on provider networks, 597 thereby turning the attention not to the specific applications of DLT 598 but what their realization may mean to the underlying network 599 operators. 601 Although attempting from the onset to base our insights on actual 602 experiments we conducted, we recognize that those insights are only 603 the start to a possibly wider understanding beyond this initial work. 605 We therefore solicit not only feedback on the specific findings 606 presented in the previous sections, but also to specific questions 607 that our work has led to: 609 1. Correctness of observed DLT behaviour: Is our observed behaviour 610 correct or have we overlooked important aspects? 612 2. Transfer of insights: Our insights so far are based on the 613 Ethereum DLT system. How transferable are the observed patterns 614 of communication onto other DLT systems that are in use? 616 3. Applicability of other network innovations: What other network 617 innovations may address the specific impacts we identified in our 618 study? Which ones beyond the ones currently listed should be 619 included? 621 Beyond the above rather high-level questions, our work has led to 622 rather specific questions that we intend to better understand. 623 Future revisions of this draft will likely extend on those in more 624 details. 626 10. Conclusions 628 This draft is a living document, originating from an initial study in 629 the impact of DLTs on provider networks [IIC_whitepaper]. 631 As such, the authors solicit feedback from the wider DLT and network 632 community to improve on the insights, transfer them onto more DLT 633 systems, and shed light onto how possible network innovations could 634 improve on the identified issues. 636 11. Security Considerations 638 TBD 640 12. Privacy Considerations 642 TBD 644 13. IANA Considerations 646 This draft does not request any IANA action. 648 14. Acknowledgements 650 This draft acknowledges the work done in the IIC Industrial Digital 651 Ledger focus group, leading to the whitepaper in [IIC_whitepaper]. 652 We would like to thank the co-authors of this whitepaper for their 653 work, specifically David Guzman (Huawei Technologies), Abhijeet 654 Kelkar (GEOOWN Consulting), Xinxin Fan (IoTex), Mike McBride 655 (Futurewei Technologies), Lei Zhang (iExec), Ulrich Graf (Huawei 656 Technologies) and Dirk Trossen (Huawei Technologies) but also Stephen 657 Mellor (IIC staff) who oversaw the process of organizing the 658 contributions. 660 15. Contributors 662 TBD 663 Email: other@foo.com 665 TBD2 666 Email: other2@foo.com 668 16. Informative References 670 [DINRGref] "Decentralized Internet Infrastructure (dinrg)", WG DIN 671 Research Group, 672 . 674 [DLT_intro] 675 Antonopoulos, A. M., "Mastering Bitcoin, 2nd Edition", 676 Book O'Reilly Media, Inc., 2017, 677 . 680 [DLT_intro2] 681 Rauchs, M., Glidden, A., Gordon, B., Pieters, G., 682 Recanatini, M., Rostand, F., Vagneur, K., and B. Zhang, 683 "Distributed Ledger Technology Systems: A Conceptual 684 Framework", Report Cambridge Centre for Alternative 685 Finance, 2017, . 689 [I-D.farrel-irtf-introduction-to-semantic-routing] 690 Farrel, A. and D. King, "An Introduction to Semantic 691 Routing", Work in Progress, Internet-Draft, draft-farrel- 692 irtf-introduction-to-semantic-routing-03, 22 January 2022, 693 . 696 [IIC_whitepaper] 697 Trossen, D., Guzman, D., Kelkar, A., Fan, X., McBride, M., 698 Zhang, L., and U. Graf, "Impact of Distributed Ledgers on 699 Provider Networks", Whitepaper Industry IoT Consortium 700 Whitepaper, 2022, . 704 [SarNet2021] 705 Glebke, R., Trossen, D., Kunze, I., Lou, Z., Rueth, J., 706 Stoffers, M., and K. Wehrle, "Service-based Forwarding via 707 Programmable Dataplanes", Paper 1st Intl Workshop on 708 Semantic Addressing and Routing for Future Networks, 2021. 710 [SOI] Jiang, S., Li, G., and B. Carpenter, "A New Approach to a 711 Service Oriented Internet Protocol", Paper IEEE INFOCOM 712 2020 - IEEE Conference on Computer Communications 713 Workshops (INFOCOM WKSHPS), 2020. 715 Authors' Addresses 717 Dirk Trossen 718 Huawei Technologies 719 Munich 720 Germany 722 Email: dirk.trossen@huawei.com 724 David Guzman 725 Huawei Technologies 726 Munich 727 Germany 729 Email: david.guzman@huawei.com