YT YouTube2Text

YouTube2Text → Transcripts → Network Topology Series: How Network Topology Impacts Throughput

Network Topology Series: How Network Topology Impacts Throughput — Transcript

by Optimum · 2,382 words · 353 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:07Hello everyone. It's been a little while
0:09since we've been at the board, but here
0:11we are. I have a piece of board all
0:14cleaned up uh for us to talk about
0:17networking today. Um and as we approach
0:22this festive season, what best to talk
0:25about than capacity and throughput in
0:28networks? Um, we talk a lot about delay,
0:33throughput, etc. Uh, and I'd like to
0:36just put a little bit of clarity and
0:38structure around how we can talk about
0:41these different um, measures of
0:44performance in networks. And it will be
0:47really good for us to have something in
0:49our mind ahead of a little series of
0:52conversations that I want to have uh
0:55around the internet protocol and
0:57particularly our role in the internet
0:59protocol for web 3. How optimum is
1:02really creating the internet protocol
1:04for web 3. Uh so let's talk a little bit
1:07about networking and what is a network.
1:10So a network effectively uh which we
1:13generally present as a graph. A graph
1:15made out of nodes
1:17uh that are connected with what we call
1:20edges which correspond effectively to
1:24either physical or generally notional
1:27links. So logical links between those
1:30nodes. Um, a network can generally be
1:33represented as a graph and it's
1:35basically just a collection of these
1:37nodes uh connected with uh these links
1:41or edges. Um, and I'd like to look at
1:45effectively two
1:48opposite
1:50cases of what a network can be. Um and
1:56what we'll see is that effectively this
1:58will really help us to think about
2:01different types of networks uh what we
2:03sometimes call topologies which is
2:05really a very fancy word for how these
2:07graphs look. So here I have the simplest
2:10network. I have two nodes uh one node
2:12talking to another and let's think of
2:14this as being what we call birectional.
2:16So they can talk to each other.
2:22Um so suppose that we have a bunch of
2:26nodes that want to talk to each other
2:28and in particular let's assume that
2:30we're in the situation with this node
2:32which we're going to call the sender
2:35and for instance in blockchain the
2:38sender could be the proposer. Okay so
2:41block proposer uh and then we're going
2:44to have different receivers sometimes
2:47called by RX. L RX1,
2:52RX2 and so on all the way to RXN.
2:57The sender is sending to these receivers
3:00and these receivers for instance might
3:02be um validators. Okay, that are
3:06basically going to validate what the
3:08sender sent. Uh so this topology is what
3:11we call generally a star topology
3:14because you know if instead of putting
3:15all the receivers down here I just put
3:18them all around the sender then it would
3:20look like a star. Again as I said
3:23perfect for the season. Um so what
3:27happens here? Well a sender sends to the
3:29receivers. So in a way this is like the
3:31most natural
3:33uh or you know first
3:37to come to mind type of topology or
3:40graph that you would think in order to
3:42have a sender talk to different
3:44receivers it just sends it to all of
3:45them.
3:50So the nice thing here is the sender is
3:52only a single hop from each receiver.
3:55So you would say well maybe delay was it
3:58doesn't look too bad. Uh the problem
4:00however is that all of these different
4:04links that I've shown here separately
4:07are actually generally all really
4:11coll-located in a single outgoing link
4:14in the input output of that receiver. So
4:17what happens is that this picture this
4:20logical picture hides an underlying
4:24physical reality which is that you know
4:28the sender generally doesn't have a
4:31dedicated link to each and uh all of
4:34those receivers. it generally has a
4:37single link that comes out of the center
4:39and then these are all actually just
4:42logical links and we'll see later how
4:45the internet protocol
4:48um suite of solutions actually creates
4:51these different logical links. So um if
4:55we normalize everything to a capacity of
4:58one really what happens here is that
5:00there's outgoing capacity of only one
5:04from the center. And so each of these
5:08individual logical links or edges
5:12actually has a capacity or total maximum
5:16throughput that's what capacity is of 1
5:20/ n.
5:23So it looks like you know maybe the
5:25propagation speed is pretty good but
5:27actually what happens is that your
5:30throughput is not that good. Um one of
5:33the ways that you could do this is you
5:35could do what's called time division. So
5:37the sender could first send to receiver
5:40one next to receiver two go basically in
5:44a roundroin way then come back to
5:46receiver one when it's done with
5:48receiver N. That's one way of splitting
5:50the bandwidth. Or you could split the
5:53bandwidth by just talking to all of them
5:55at once but sending fewer packets fewer
5:59uh quanta of
6:02um information. So this is one extreme.
6:06So here if you look at the throughput
6:09that each of these receivers can have uh
6:13it's basically the capacity it's
6:15basically 1 /x.
6:18Okay.
6:19Now um if you look at uh this topology
6:24and say well do we know anything uh
6:26currently in blockchain that looks like
6:28that actually yes we do. Um if you
6:31consider the Alpenlow system which is
6:35the next version coming up for Salana,
6:38it actually has exactly this star
6:41topology or exactly this construction um
6:45for the underlying graph.
6:51Um, there's a little bit of a trick here
6:54in that
6:56some of the traffic here might be what
6:59we call lost, which is not necessarily
7:01that it was a loss loss, but it was
7:02delayed enough that it looks like it
7:05didn't get there. So, let's just say it
7:07didn't get there on time for it to
7:09matter. U, so there's going to be an
7:12extra matter here that we're going to
7:14call a one over epsilon. So rather than
7:18being a full one, there's some epsilon
7:21that we're losing
7:24to the losses
7:26in the system. Okay, so maybe rather
7:30than being 1 / n, it's 1 minus epsilon
7:35to the n. And the reason people add
7:40coding and of course some of our earlier
7:43sessions at the board have talked a lot
7:45about coding is actually really to deal
7:47with this epsilon. This epsilon may not
7:49be huge by the way. It may be just a few
7:52percent. Uh so it's going to show up and
7:55you may say at this point well you know
7:57the n is pretty large like if you think
8:00again of say salana that's like 200
8:03right? So you're like, "Okay, Mariel,
8:05you know, you're dividing by 200 and
8:07maybe you're subtracting here like 0.1,
8:10you know, do I really care about the
8:120.1? That's not the biggest deal." Let's
8:14keep that in mind and let's look at the
8:16next example. So here we go. This is
8:20basically my star topology.
8:28We're going to look at the other extreme
8:30of topologies and that's going to be
8:33basically a daisy chain.
8:37So what happens in this daisy chain is
8:40that I'm going to have my sender.
8:44Okay,
8:47like before. And then I'm going to have
8:49all of these receivers. But the
8:51receivers are just going to be relaying
8:54to each other.
8:58So receiver n minus one. So receiver two
9:00and so on. Okay. So basically each of
9:04them is just connected to the next one.
9:08All right. We're still going to have
9:10this epsilon losses on each of these
9:12links. So I'm going to have one minus
9:14epsilon here etc.
9:17All right. Let's look at the throughput
9:19of what I can get here in this system.
9:22Well, I can get the full one minus
9:24epsson going from the sender to this
9:26receiver because I'm not splitting up
9:29the bandwidth like I did before. This
9:32sender only talks to this node and so it
9:34can dedicate all of its bandwidth to
9:37talking to that node. It doesn't have to
9:40share it with other people. But then
9:43this node is also going to talk uniquely
9:46to the next node.
9:49So all of its bandwidth is being
9:51dedicated. So every time I have this one
9:55minus epsilon. So the total throughput
9:59that I should be able to get here is
10:01actually one minus epsilon. So if I have
10:07this sort of daisy chaining as opposed
10:10to having this as a throughput that the
10:13sender can get to any one of the
10:14receivers
10:16because we have these relays here the
10:19sender can actually get the full one
10:21minus epsilon because remember that when
10:24we have in a blockchain a proposer it's
10:28actually sending the same thing.
10:31So here it's having to copy things to
10:34all of these different receivers, but
10:37here it basically sends everything to
10:39receiver one who's going to send
10:41everything to the next node and so on.
10:43So my throughput here looks fantastic.
10:47One minus epsilon.
10:54Now this is the maximum maximum
10:58achievable throughput. But remember the
11:00coding that we talked about. Here the
11:03coding is being done at the sender and
11:06then decoded independently at each of
11:09the receivers.
11:11What about here? Well, you could have
11:14the sender code to receiver one.
11:18Receiver one decode, then send to the
11:21next receiver after having recoded it or
11:25re-encoded it. Receiver two decodes,
11:28etc. problem is this is going to take a
11:30long time and as we'll see later
11:33sometimes it's just not possible.
11:37Um instead what people do is they use
11:41things like for instance as you see in
11:45uh turbine which is reolman codes or as
11:49you see in something um like raptocast
11:53for monad is they will use a code which
11:58is end to end and in that case what
12:01happens is that a packet has to get
12:04through each of these
12:07links. Okay, so it has to get through
12:10the first one and that happens with
12:12probability 1 minus epsilon that it's
12:15successful.
12:17Then it has to get through the second
12:19one probably 1 minus epsilon all the way
12:23to if you look at the very last one also
12:26one minus epsilon. So it's 1 - epsilon *
12:291 - epsilon etc etc etc. The throughput
12:33is one minus epsilon to the n
12:38if you do an n to end code. So that's
12:41really really far from the optimum
12:44throughput. As a matter of fact,
12:48even if my epsilon is not very big, say
12:50it's 0.1. So it's like 90% probability.
12:53If I have an n which is large, say 200,
12:57this is going to zero.
13:00Okay, it's going to zero exponentially
13:03actually with the number of nodes,
13:06right? Which is why a lot of systems
13:09haven't done this. So if you think of
13:11something that's uncoded
13:15like gossip sub for Ethereum, it's
13:18basically not quite doing this. It's
13:21trying to limit how many hops it has and
13:24it's kind of trying to manage, you know,
13:27um manage the problem. uh but
13:29effectively this is going to go down
13:33exponentially
13:35with
13:37uh with the number of notes uh
13:40approximation is that it goes basically
13:42as 1 minus n epsilon which means that
13:46you know if your epsilon is say 0.1 with
13:5010 of these you're basically at zero
13:54so disaster complete disaster
14:02Now what happens when you use RLNC?
14:06You encode
14:08and then without decoding you re-encode.
14:12Without decoding you re-encode and it
14:15turns out that you get this throughput.
14:19So the throughput actually is the
14:23optimum throughput that you would get if
14:26you were say sending
14:29everything decoding
14:32then coding again sending decoding which
14:36of course would take a long time.
14:43So you can see that this topology
14:47um is actually giving you a much lower
14:52throughput from the sender to each
14:54receiver.
14:56This topology is giving you a much
14:58higher throughput. Now here in terms of
15:00number of hops of course you have to go
15:02through n hops right um but you know
15:07speed of light it's very high. So if uh
15:10even in very simple systems that are you
15:15know basically public internet you you
15:18get something often very close to that.
15:21So you may have a little bit more delay
15:23but your throughput is higher here. You
15:25have fewer hops but your throughput will
15:27be lower.
15:29uh and we'll talk a little bit more
15:30about meshes and other things next time
15:33but basically what the internet protocol
15:36is trying to do is it's trying to manage
15:39the throughput and the delay. Uh one of
15:43the things to know here is that another
15:45way that you could try to operate this
15:48and the way uh internet protocols do
15:50right now is that instead of coding um
15:54they actually when something didn't get
15:56through they go back and ask for it.
15:59Same issue would happen. You would still
16:01get this exponentially decreasing
16:04throughput which means that the scaling
16:06basically sticks. Notice that here I
16:09actually don't even care how many nodes
16:11I have. Even if I have a really really
16:14large network arranged in this fashion,
16:18my throughput is entirely scale free. So
16:21in terms of scaling here, you get a
16:24perfect scaling in throughut and that's
16:27basically what we're doing with optimum.
16:35So most networks fall somewhere along
16:38these uh in the spectrum between these
16:40two extremes. Uh for instance, if you
16:43look at something like uh Monad's raptor
16:45cast or the current version uh of
16:49Salana, which is turbine, what they'll
16:52have is not something that's quite like
16:54this. They'll have a few extra nodes. So
16:56they'll take basically a version where
16:59there's a little bit of this kind of
17:01embedded in that. Um, if you look at
17:04something like Ethereum, you'll see a
17:07system which is like a little closer to
17:09the daisy chain, but what we call a
17:12mesh. We'll talk about meshes next time,
17:14but these are really helpful extremes to
17:18bear in mind the two opposite ends of
17:22how you can actually manage a network
17:25with a given number of nodes, a sender
17:28and multiple receivers. All right. So,
17:31um, with that, uh, we'll pick up here
17:34next time and talk a little bit about
17:36how the internet protocol that, uh,
17:38protocols that are out there try to
17:40manage this and how we manage it.

About this transcript

This page contains the full transcript of Network Topology Series: How Network Topology Impacts Throughput by Optimum, generated from the public captions YouTube serves with the video. The transcript has 2,382 words across 353 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.