3 of 32

Properties of Links

A link connects two devices.

Properties of a link:

Bandwidth: Number of bits sent/received per unit time.

"Width" of the link.
Measured in bits per second (bps).

Propagation delay: Time it takes a bit to travel along the link.

"Length" of the link.
Measured in seconds.

Bandwidth-delay product: Bandwidth × delay.

"Capacity" of the link.

Capacity = Delay × Bandwidth

Bandwidth

Propagation Delay

so far we've been drawing

38:56

things like this we draw two circles and we draw a line between them and we say this is a link so what is a link well

39:04

it's something that connects two devices and it has some properties so here are some three properties that we care about

39:11

one of them is bandwidth band with says how many bits can you send or receive on

39:17

this link per unit time so the way you measure it is data per unit time and so

39:25

the most common unit of measurement is bits per second BPS and derivations

39:31

thereof so for example Mbps is megabits per second kbps is kilobits per second

39:38

and one thing I want to point out and it's very annoying and it trips me up all the time BPS is bits per second it

39:44

is not bytes per second those are different things and they're off by a factor of eight because there are eight

39:50

bits in a bite so if I see that this link works at 8 bits per second that's

39:56

one byte per second and sometimes in real life people use these two interchangeably which is kind of

40:02

annoying but just remember that to go from bits to btes there's a factor of eight because there are eight bits in a

40:08

bite kind of annoying but something you have to deal with the second property is propagation delay and this property it

40:15

seems like it's the same as bandwidth but if you squinted it they're very different things bandwidth says how many

40:21

bits can I receive per unit time propagation delay by contrast says how

40:26

long does it take to travel across the link so if I just send a single bit how

40:31

long does it take from the instant the bit is sent to the instant that the bit is received and this is just a unit of

40:37

time so we're just measuring how much time it takes to send the bit across the link and if this still doesn't totally

40:43

make sense I have an analogy for you so let's say that this link is like a pipe so you can think of a pipe that's

40:49

carrying water and we can say that the pipe has bandwidth and the bandwidth of

40:55

the pipe would be how wide the pipe this so if this link has very small bandwidth that's equivalent to a pipe that's very

41:02

narrow and if it's very narrow that means that the amount of water you can send through the pipe per unit time is

41:08

very slow you have a very narrow pipe and you pump water through it the amount of water that trickles out on the other

41:15

end it's not going to be a lot of water by contrast if you have a really big pipe it's really big you can like walk

41:21

inside of it then if you try to shove water through this pipe the other side is going to be flooded really quick

41:27

quickly it's going to be flooded with all the water that you're sending through the pipe so intuitively you can

41:32

think of bandwidth as how wide your pipe is how much water can you shove through this pipe per unit Time by contrast

41:40

propagation delay is the length of the pipe so it's saying how long is the pipe if the pipe is connecting me to my next

41:47

door neighbor not very long if the pipe is connecting San Francisco to New York that's a very long pipe and the pipe

41:53

tells us how long does it take for a single drop of water to travel from one end to the other so as I'm sending water

42:00

through the pipe I can start a timer the instant a drop of water enters the pipe and stop the timer when that same drop

42:07

of water exits the pipe and see how long that takes and notice that these two things they're not really connected to

42:13

each other in any way you can increase one and not increase the other they basically change independently of

42:19

independently of each other for example I can make the bandwidth much wider that is I can shove a lot more water through

42:25

the pipe now but the propagation delay stays the same just because I can shove a lot of water through the pipe if the

42:32

pipe is still really long it's still going to take a lot of time for any individual drop to travel across the

42:37

pipe and likewise if I make the propagation delay long or short well

42:42

that doesn't affect the bandwidth it just means that the water takes less time to travel through but if the pipe

42:48

bandwidth stays the same it's still the same amount of water showing up just takes less time for each individual drop

42:54

to show up so all of this is to say bandwidth and obligation delay are two totally separate properties and they're

43:00

not really related to each other in any meaningful way and the third property is

43:06

actually a combination of these two so it's called the bandwidth delay product and it's just taking these two terms and

43:12

multiplying them together so notice that bandwidth is bits per unit time and

43:17

propagation delay is time so if you think about multiplying bits per second

43:22

and you multiply it by seconds the output is just going to be bits just or rearranging the units a little bit but

43:29

basically the bandwidth delay product if you multiply these two values together you'll get roughly the capacity of the

43:35

link and in the water analogy I would think of this as if you freeze time so

43:40

you stop time for one second or however long and you measure the amount of water in the pipe at that instant that's the

43:48

bandwidth delay product that's how much water can fit in the link at any given instant

4 of 32

Measuring Packet Delay with Timing Diagrams

Suppose we have a link with:

Bandwidth = 1 Mbps. (1,000,000 bits per second.)
Propagation delay = 1 ms. (0.001 seconds.)

How long does it take to send a 100-byte (800-bit) packet?

From the time the first bit is sent,
To the time the last bit is received.

Let's draw a timing diagram to help.

Note: We measure in�bits per second, not bytes!

can start doing performance calculations for how long it takes to send some amount of data through a link so as a

44:35

running example let's say we have a link with a bandwidth of one megabit per

44:40

second and one megabit is 1 million bits so this means that this link can send 1

44:45

million bits per second again remember not to confuse this with bytes these are bits and the propagation delay is 1

44:52

millisecond which is 0.1 seconds that is how long it takes for for a single bite

44:59

to enter the pipe and then exit the pipe so you enter the pipe at any time and it

45:05

leaves one millisecond later okay so the question we're going

45:10

to try to answer is let's say we have a packet that is 100 bytes how long does it take to send this packet from the

45:17

instant that the first bit is sent to the instant that the last bit is received so in total from the instant

45:24

that the sender starts shoving data into the pipe to the instant that the final bite or bit exits the pipe

5 of 32

Measuring Packet Delay with Timing Diagrams

Bandwidth: 1,000,000 bps

Delay: 0.001s

t = 0s

t = 0.000001s

Time to transmit each bit:

1/1,000,000s

t = 0.001001s

Each bit arrives�0.001s later.

t = 0.000002s

t = 0.001002s

t = 0.000003s

t = 0.001003s

t = 0.000800s

t = 0.001800s

Time to transmit 800th bit:

800/1,000,000s

Last bit arrives 1.8 ms later.

800-bit packet

okay so here's the picture there's our link goes

45:56

from A to B the bandwidth as mentioned earlier is 1 million bits per second and the delay is .1 seconds so this diagram

46:05

is going to show us what happens over time so we're going to start with time zero and as you move down this diagram

46:11

time will increase so at Time Zero a is going to send the very first bit so

46:17

there are 800 bits to send and a is going to take that very first bit and throw it into the pipe so in it goes and

46:25

remember that each bit takes one over one million seconds to send because I

46:31

can send one million bits in one second that means that each bit takes one over

46:37

1 million bits or seconds sorry to send so I'm just taking this value inverting

46:42

it or taking the reciprocal this tells me how long it takes to send each bit into the pipe so the bandwidth allows us

46:49

to realize that at Time Zero I throw one bit into the pipe and then one millionth

46:55

of a second later I throw the next bit into the pipe and 1 millionth of a second later I throw the next bit into

47:00

the pipe this is the rate at which I can throw bits into the pipe so one

47:05

millionth of a second later the next bit shows up or rather the first bit I guess

47:10

shows up so this is how long it takes to send each bit at time equals zero I start throwing in the first one and it

47:16

enters the pipe at Time 1 millionth of a second and once it enters the pipe it

47:22

takes 0.1 seconds to pop out of the other side so by the time the packet reaches the

47:28

other side it is now 0.1 seconds later so if you squint at this this is 0.1 the

47:35

amount of time it takes to travel through the pipe plus 1 millionth which is the amount of time it took to send

47:41

this packet or send this bit into the pipe in the first place so that's the

47:46

first bit arriving so this is the time at which the very first bit arrives then what happens next well one

47:53

millionth of a second later sender a sends the next bit into the pipe you throw it into the pipe and again 0.001

48:01

seconds later it shows up on this side and this is going to happen 800 times because there's 800 bits to send so at

48:09

time three millionth we throw another bit into the pipe 01 seconds later shows

48:14

up on the other end so it's 0.1 plus 3 millionth of a second and so this keeps

48:21

going over and over again and eventually we get to the 800th bit and that's going to be sent at 800 millionth of a second

48:29

after the first one so the first one was sent at 1 millionth 2 millionth 3 millionth all the way up to 800

48:36

millionth which happens to be this number it's okay if these numbers don't you don't have to compute these right

48:42

now just tles on the slide and 0.1 seconds later that packet arrives on the

48:48

other side as well and so this is our final answer this is when the final bit arrives at the recipient it arrives at

48:58

0.008 that's when the bit enters the pipe and it arrives at

49:04

0.180 0 that's when it exits the pipe so if you're really careful with these calculations and really do the math

49:10

you'll realize that this packet takes 1.8 milliseconds to arrive at the end

6 of 32

Measuring Packet Delay with Timing Diagrams

Packet Delay = Transmission Delay + Propagation Delay

Packet Delay = (Packet Size / Bandwidth) + Propagation Delay

Bandwidth: 1,000,000 bps

Delay: 0.001s

t = 0s

t = 0.000001s

t = 0.001001s

t = 0.000800s

t = 0.001800s

800-bit packet

Transmission Delay

Propagation Delay

f you're

50:30

really looking for the formula roughly speaking this is how we computed it so this is the math that we did so we took

50:36

the packet size that was 800 bits and we divided it by the bandwidth so this

50:42

number in red gave us 800 millionth of a second basically tells us when the last

50:48

bite shows up so maybe another way of thinking it of it is one over bandwidth is how long it takes to send one bit and

50:55

you have packets size number of bits so in total if each one takes one over bandwidth to send and you have packet

51:02

size number of bits the total amount of time it will take to just get everyone in the pipe is Packet size over

51:08

bandwidth and that's this time right here this is the amount of time it takes to just get everyone into the pipe

51:14

regardless of what happens on the other side so the sender has to get until T equals 800 millionth of a second just to

51:22

get everyone into the pipe and this term actually also has a special term we call it transmission delay it's the amount of

51:29

time it takes just to shove everyone in the pipe regardless of what time they actually show up on the other side and

51:35

because this is the time it takes to just get everyone in the pipe by the time the last person enters the pipe or

51:41

the last bit we also have to wait one more propagation delay for that last bit to exit so at the time the last bit

51:48

shows up wait one more propagation delay the last bit exits the pipe and that gives us our final answer so in total

delay comes from two sources one is the transmission delay and it's affected by packet size and bandwidth the more

52:01

packets you have the longer it takes to shove everyone in the pipe and the narrower the packet the pipe is the

52:07

longer it takes to shove everyone into the pipe that's the bandwidth and the second term is propagation delay the

52:13

longer the pipe is the longer it takes for packets to show up and we have one term of propagation delay at the end for

52:19

the last packet to show up all the other packets show up earlier so we don't have to add them in this

52:25

calculation that is is to show up up here so if you really needed the magic

52:30

formula it's this but be ready to draw the timing diagrams to really apply your

52:37

knowledge

7 of 32

Link Tradeoffs

Which link is better? It depends.

Link 1: Bandwidth 10 Mbps Propagation Delay = 10 ms
Link 2: Bandwidth 1 Mbps Propagation Delay = 1 ms

10-byte packet: Link 2 is better.

~10 ms with Link 1. ~1 ms with Link 2.
For small packet, transmission delay is negligible. Propagation delay dominates.

10,000-byte packet: Link 1 is better.

~18 ms with Link 1. ~81 ms with Link 2.
For large packet, transmission delay dominates.

okay so now that we know how to calculate the performance of links and use these performance attributes to

52:44

calculate how long it takes to send packets through the network we can now start comparing links if you go to the

52:50

store and try to buy some links you might think which of these is better and as always the answer is there's not a

52:56

clear way there are tradeoffs so for example let's say you go to the store and you have these two choices of links

53:01

one of them has high bandwidth but low Pro but High propagation delay as well so the link is high bandwidth you can

53:07

shove lots of water through it but it's very long takes a lot of time for the packets to show up by contrast the other

53:14

link has smaller bandwidth it's very narrow can't send a lot of water through it at any given time but the propagation

53:20

delay is quite short so each packet that you send in shows up pretty quickly and so immed imately you think which of

53:27

these is better and the answer is it kind of depends on what data you're trying to send so for example let's say

53:33

you're sending a pretty small packet 10 bytes that's a pretty small packet well if you think about sending a 10 byte

53:39

packet you can do the calculations that we just did and in fact if all of this is seeming like just some wizard magic

53:45

maybe you do want to sit down and actually crunch out these calculations you'll get roughly 10 milliseconds for

53:50

link one 1 millisecond for link two so you can actually run some calculations to prove Pro to yourself that link to is

53:58

the winner here but intuitively here's how I think about it this packet is very small so regardless of what the

54:04

bandwidth is the amount of time it takes to shove this packet into the pipe is pretty quick there's only 10 bytes that

54:11

you have to shove into the pipe so regardless of if my bandwidth is 10 megabits per second or 1 megabit per

54:16

second I'm basically going to be done shoving this packet into the bite into the pipe instantly cuz it's so small and

54:23

so this means that most of the delay is going to come from the propagation delay it's going to come from the time it

54:28

takes for this tiny little packet to travel all the way across the pipe so if I just have a little burst of water that

54:34

I have to send in both cases getting the water in the pipe is not the problem it's the amount of time it takes to

54:40

travel across the pipe that's really going to dominate in that case I want the shorter pipe because I want this

54:46

packet to get there as fast as possible and we know propagation delay is the main problem here so pick the one with

54:52

lower propagation delay here's the other case what if the packet is 10,000 bytes very big packet

55:00

well in this case again you can crunch the numbers you'll get roughly 18 milliseconds for link one 81

55:06

milliseconds for link two unless I messed up my math and if I did let me know but intuitively now the

55:13

transmission delay is the one that dominates this is a lot of data to shove into the pipe so now we really want the

55:20

big pipe we want the one where you can shove all the stuff into the pipe as fast as possible and Link one has the wi

55:26

bandwidth it's going to let us get all of these packets into the pipe and yes the propagation delay is worse but in

55:32

this case because there's so much to shove into the pipe the transmission delay dominates and compared to the

55:38

amount of time it takes to shove the packets into the pipe the propagation delay is very small doesn't really make

55:44

a noticeable difference the transmission delay is what you really feel as the limiting factor the one that makes this

55:51

packet transmission slow so it really depends in this case for packets that are small the propagation delay is the

55:57

one that dominates and you really care about optimizing for that but if you're sending large packets maybe the transmission delay dominates and in that

56:04

case you want the one with wider bandwidth and if you're sending mediumsized packets who knows you have to do the calculations yourself and

56:11

really think about what link is best for your purposes so those are some trade-offs and you can see sometimes it

56:17

requires back at the envelope calculations in addition to just thinking about things

56:25

intuitively

8 of 32

Pipe Diagrams

Lecture 3, CS 168, Spring 2026

Links

Bandwidth and�Propagation Delay
Pipe Diagrams
Overloaded Links

Brief Preview of the Semester

9 of 32

Timing Diagrams and Pipe Diagrams

Bandwidth: 5 bps

Delay: 7s

t = 0s

t = 1s

5 bits transmitted per second.

t = 8s

Each bit arrives�7s later.

t = 2s

t = 9s

t = 3s

t = 10s

t = 17s

10s to transmit 50 bits.

Last bit arrives 17s later.

50-bit packet

Okay so we've just seen one way to draw out links we saw the timing

57:35

diagrams and we can use those to measure the performance of a link but there's actually an alternate way of drawing

57:41

links and this one honestly kind of threw me off at first so I tried a couple of animations to make it look

57:47

better let me know what you think they might be kind of weird but we'll try it so as a reminder we drew timing diagrams

57:54

and timing diagrams I think they're great the way you read them is relatively simple time starts at the top

58:00

and it works its way down and the way that we drew it is we basically said

58:05

well each line represents some amount of bytes being sent from A to B and we can

58:11

draw the place or the time where that set of bytes is sent and the time at which that set of bytes is received and

58:18

we can use this to help us calculate how long it takes for packets to be sent so for example here's another example with

58:25

slightly more easy to stare at numbers so we have a link with bandwidth that sends five bits per second and a delay

58:32

of 7 seconds is this realistic no is it easier to draw on the slides yes so we'll go with this so here's a case

58:39

where I can send five bits at every second so maybe another way of drawing the timing diagram from before instead

58:44

of drawing each bit individually I can draw well at 1 second five packets enter

58:50

look at the dots 1 2 3 4 5 those are the five bits that entered and each arrives 7s later

58:56

10 of 32

Timing Diagrams and Pipe Diagrams

The pipe diagram is an alternate view of the link.

Shows the bits on the link at a frozen moment in time.

Bandwidth: 5 bps

Delay: 7s

t = 0s

t = 1s

t = 2s

t = 3s

t = 4s

t = 5s

t = 6s

t = 7s

t = 8s

t = 9s

t = 10s

t = 11s

t = 12s

t = 13s

t = 14s

t = 15s

t = 16s

t = 17s

(This diagram needs to be viewed with animation to make sense.)

I am showing to you is a frozen moment in time so I am causing the movie to

1:01:27

show you where the bits are at any given time if the bits are on this side outside of the blue pipe they are still

1:01:34

at a waiting to be sent if the bits are on this side outside of the blue pipe

1:01:40

they have been received by B and crucially if they are inside the Blue Zone they are wait or they're currently

1:01:47

being sent through the pipe that's how I drew this and in general when people draw this they mainly draw the thing in

1:01:53

blue and that's going to show you a Frozen in Time picture of the pipe it's

1:01:59

like pausing the movie to see what's going on inside of the pipe so at time equals z none of the bits have been sent

1:02:06

they're all waiting at a to be sent and what happens in time equals 1 well we

1:02:12

can send five bits so look what happened five of the bits entered the pipe there

1:02:17

they are and have they reached B yet no because there's a delay so they're still in the pipe and they're not going to

1:02:23

reach B until 7 seconds later so they're going to enter the pipe now and 7 seconds later they're going to show up

1:02:29

at B so what happens at time two well you guessed it five more bits enter the

1:02:35

pipe check it out five more bits enter the pipe and also the five bits that

1:02:40

entered at time equals 1 that would be these bits right here they took a step they started to approach B so again

1:02:46

we're watching the bits move from A to B we're just doing so with taking snapshots every second so we're pausing

1:02:53

the movie okay so one more second elapses another set of five bits marches

1:02:59

in this set right here marches into the pipe and again the bits that were

1:03:05

already in the pipe take a step forward so what happens next I'm equals four they March again I'm equals 5 they

1:03:12

March again and notice nothing has arrived at B yet because we said the delay is 7 seconds so and we're still at

1:03:18

time equals 5 Seconds nothing has shown up yet okay time 6 something marches in

1:03:24

time seven bite marches in so at this point the pipe is full by the way so before it wasn't now it's full

1:03:30

that's something you can only really observe with these pipe diagrams another reason for drawing these but basically

1:03:35

remember earlier so I'm going to rewind a little bit remember how this one entered at time equals 1 and we said the

1:03:41

delay is seven so if these bits enter at time equals 1 and the delay is seven

1:03:46

well when when's it going to show up on the other side 1 + 7 is8 so we fast

1:03:51

forward back here let check it out at 10 equals 8 those bits show up at B they

1:03:56

exit the pipe B receives them and these bits they entered at time equals 2 right

1:04:02

behind the ones at time equals 1 so if these enter at time equals 2 and they have a delay of 7 Seconds they're going

1:04:08

to show up at 2 + 7 = 9 and there they are they show up at time equals 9 and

1:04:14

you kind of get the idea the next family arrives at time equals 10 and then 11

1:04:19

and 12 and so on and what we're seeing here is that for any given set of bits

1:04:25

they March into the pipe and 7 seconds later they March out on the other end so we basically just watch the bits travel

1:04:32

across the pipe from A to B and by using this picture we got the same answer of

1:04:37

17 seconds it was still 17 seconds from the start to the end you could have also gotten this by plugging it into the

1:04:43

formula or drawing the equivalent timing diagram like we did earlier this is the pipe diagram you draw a rectangle and

1:04:51

the rectangle has bits marching through it it's a little bit weird you have to

1:04:57

stare at it for a little bit and play with the animation a little bit to really get the hang of it but that's what it looks like and I've made this

1:05:05

animation for you to look at you can rewind you can fast forward whatever you want

1:05:11

okay and yes please watch this with animation if you watch this without animation it looks like complete trash

1:05:16

so this makes no sense but if you play with animation it looks great so do that

1:05:21

okay see it's so nice okay enough enough playing with this so uh that's how you view this diagram view with animations

11 of 32

Pipe Diagrams

Pipe diagram shows the bits on the link at a frozen moment in time.

Height = bandwidth. How many bits we can put in the pipe per unit time.
Width = propagation delay. How long it takes for bits to travel through the pipe.
Area = bandwidth-delay product. How many bits fit in the pipe at a given instant.

Bandwidth: 5 bps

Delay: 7s

Bandwidth

Propagation Delay

in real life what they really care about is the

1:05:41

rectangle itself they want to draw this rectangle as a visual representation of

1:05:46

the pipe so that they can analyze what fits in the pipe at any given time and the way that they draw this pipe is or

1:05:53

sorry this pipe yeah H the way that they draw this pipe is based on the rectangle

1:05:58

and the rectangle is based on the two properties that we already talked about so they're going to draw this pipe using

1:06:05

the bandwidth to determine the height and remember we talked about this earlier the bandwidth tells us how many

1:06:11

bits we can fit in the pipe so the reason why I added this crazy animation is because I wanted to show you that if

1:06:17

you increase bandwidth what happens the rectangle gets taller and if the rectangle gets taller what happens it

1:06:24

means more of these bits can line up to enter the pipe at any given unit of time

1:06:30

that's why bandwidth represents the height of this rectangle so the thing that always confuses people is they say

1:06:36

why is bandwidth the height well one intuitive way of saying it is we talked about the water pipe the bandwidth tells

1:06:41

us how wide the pipe is another way of seeing it is if you look at this diagram it tells us that if the bandwidth is

1:06:48

increased it means that you can stack more of these dots which represent bits and more of the bits can enter at any

1:06:54

given time that is exactly what it means to have higher bandwidth that's why the height is determined by the

1:07:00

bandwidth and the width tells us the propagation delay again it's kind of like the water example the width tells

1:07:07

us how long the pipe is and how long it takes for a single drop of water to travel through the pipe but we can see

1:07:13

that through our little animation as well that if you make this rectangle longer these bits are going to have to

1:07:18

March for more time steps before they can exit on the other side and just like we saw earlier bandwidth times

1:07:25

propagation delay if you multiply these two terms together you get the area of this rectangle which is the capacity of

1:07:31

this pipe and again the animation shows us that this is indeed the capacity of the pipe the area of this rectangle

1:07:39

because the bigger this rectangle is whether you make it taller or wider the bigger this rectangle is the more dots

1:07:45

or bits you can fit into this pipe so hopefully with these dots I've convinced you that the pipe diagram is really just

1:07:53

a rectangle where the bandwidth is the height and the propagation delay is the width and the dots are really just there

1:07:59

for clarity but the rectangle is what people really care about when they draw

1:08:05

these and

12 of 32

Pipe Diagrams

Shorter propagation delay: Pipe length is shorter.

Bandwidth: 5 bps

Delay: 3s

t = 0s

t = 1s

t = 2s

t = 3s

t = 4s

t = 5s

t = 6s

t = 7s

t = 8s

t = 9s

t = 10s

t = 11s

t = 12s

t = 13s

(This diagram needs to be viewed with animation to make sense.)

so just to convince yourself one more time here's an

1:08:12

example where the pipe length is shorter and so what you'll notice is that the bandwidth is the same still the same

1:08:18

height so what that means is that we can still only March in five bits at any given second that's why it says five

1:08:25

bits per second only five bits can March in but now that the delay is 3 seconds instead of seven the rectangle is

1:08:32

shorter or rather Slimmer less wide so what that means is that when this sequence of five bits

1:08:39

enters the stack we'll notice that at time one it enters and then one two 3

1:08:44

seconds later it shows up on the other side and for any one of these stacks of five let's pick one okay so let's look

1:08:50

at this one right here right now it's here right now it's about to enter the pipe it enters at six 7 8 and at time

1:08:57

equals 9 it exits the pipe let's look at this very last one it enters at time 10 11 12 13 is when it shows up and once

1:09:05

again the timing diagram would have given you the same answer took 13 seconds for this stack of bits this

1:09:12

total packet to travel across the pipe so this pipe represents uh link with the

1:09:18

same bandwidth but lower propagation DeLay So less wide

1:09:26

please view with animation

13 of 32

Pipe Diagrams

Higher bandwidth: Pipe height is taller.

Bandwidth: 10 bps

Delay: 3s

t = 0s

t = 1s

(This diagram needs to be viewed with animation to make sense.)

t = 2s

t = 3s

t = 4s

t = 5s

t = 6s

t = 7s

t = 8s

okay here's another example now I'm going to keep the propagation delay the same it's

1:09:31

still three so the width of this rectangle is the same but it is now taller because the band width is wider

1:09:37

and again if you think about the water example I've increased the width of the pipe you can now shove in more dots at

1:09:43

once so by making this taller it is now the case that I cannot I can March in not five but 10 dots per second so now

1:09:52

the dots are lined up in stacks of 10 and at any second 10 of them enter and that's allowed because this pipe is now

1:09:59

taller so at time equals 1 the stack of 10 enters but the delay is still three so you still have to count one two three

1:10:07

before that stack of 10 exits and same thing with this last set right here one two three before it exits I think I

1:10:14

count it wrong okay so it enters right there and then one two three it exits and I get a total propagation time of 8

1:10:21

seconds so that's another example of a pipe diagram again people really just

1:10:26

draw the rectangle but I really like Imagining the dots inside of the rectangle to remind myself why the

1:10:32

rectangle looks like this do with animations

1:10:40

14 of 32

Pipe Diagrams – Transmission Delay

The width of the packet in the pipe represents the transmission delay.

How long it takes to put all the bits in the pipe.
More bandwidth = taller pipe = more bits in pipe per unit time�= narrower packet in pipe.

Bandwidth: 5 bps

Delay: 7s

(This diagram needs to be viewed with animation to make sense.)

t = 0s

t = 1s

t = 2s

t = 3s

t = 4s

t = 5s

t = 6s

t = 7s

t = 8s

t = 9s

t = 10s

t = 11s

okay and so one thing that people always get confused on on the pipe diagram you might be wondering okay what's with all

1:10:46

these dots why are you showing me dots this is the part that I think really trips people up because when you draw

1:10:51

these pipe diagrams you can also draw packets inside of the pipe so instead of

1:10:58

just drawing a rectangle and calling it a day what most people will do when they draw these pipe diagrams is they will

1:11:03

actually draw the packets sitting inside of the pipe that's what these diagrams

1:11:08

are really good at they're really good at giving you a frozen moment in time where you can say there's a packet right

1:11:14

here and there's a packet right here and they're currently being sent and there's a packet right here that's what's so great about these diagrams they're going

1:11:20

to let us watch packets as they go through this pipe at Frozen moments in time and we're actually going to use

1:11:26

these when we get to later when we talk about the reliability protocol TCP we're going to draw these diagrams so useful

1:11:33

to think about them I won't draw them with dots that's just for today but we will draw these diagrams so when we

1:11:39

talked about transmission delay remember that that was how long it takes to send the packet into the pipe well then the

1:11:46

transmission delay means how long does it take for all of the bits to March

1:11:51

their way into the pipe so remember transmission delay was how long does it take from the first bit being shoved

1:11:58

into the pipe to the last bit being shoved being shoved into the pipe with no regard for the output we just care

1:12:04

about a shoving all the bits into the pipe so the way that we measure that then is we start at time zero and for

1:12:11

this particular Link at five bits per second a stack of five enters at every given time step and at time equals four

1:12:19

that is when all the bits have been shoved into the pipe so the transmission delay is 4 seconds seconds this is the

1:12:26

part that I think is confusing if the bandwidth increases the pipe gets taller

1:12:32

do you agree when there's more bandwidth it gets wider the pipe gets taller you can March more bits in per unit time and

1:12:39

because more bits can be marched in per unit time the packet itself gets

1:12:45

narrower that's kind of weird the packet gets taller but it's the same amount of data it's just we're stacking them in

1:12:51

taller Stacks per unit time so the packet itself gets narrower this is the

1:12:56

bit that I think always strips people up okay I guess we have to wait for this packet to travel good it's made it to

1:13:01

the end so this is the same packet as before here was a packet that was 20 bytes but

1:13:07

I stacked them in fives because the bandwidth was five bits per second so the transmission delay was four 20 divid

1:13:15

5 and so in this case the bandwidth is now 10 which means I can stack them in t

1:13:21

instead of stacking them in fives and what you'll notice is that when I stack them in 10 tens the packet itself gets

1:13:27

narrower so right here when I draw the packet it's pretty wide it's four wide

1:13:32

which corresponds to the transmission delay of four

15 of 32

Pipe Diagrams – Transmission Delay

The width of the packet in the pipe represents the transmission delay.

How long it takes to put all the bits in the pipe.
More bandwidth = taller pipe = more bits in pipe per unit time�= narrower packet in pipe.

Bandwidth: 10 bps

Delay: 7s

(This diagram needs to be viewed with animation to make sense.)

t = 0s

t = 1s

t = 2s

t = 3s

t = 4s

t = 5s

t = 6s

t = 7s

t = 8s

t = 9s

16 of 32

Pipe Diagrams – Transmission Delay

The width of the packet in the pipe represents the transmission delay.

How long it takes to put all the bits in the pipe.
More bandwidth = taller pipe = more bits in pipe per unit time�= narrower packet in pipe.

Transmission Delay

okay so this is the picture that I

1:14:21

really care about at the very end so ultimately when people draw these again they don't draw the dots but they will

1:14:28

draw things like this they'll draw a blue rectangle to represent the link and then they will draw these orange squares

1:14:34

that represent the packets themselves and so these are actually the same packets these are three packets each

1:14:41

packet is 20 dots these are also three packets each packet is also 20 dots or

1:14:47

20 bits but notice that because the link itself changed in particular the link

1:14:52

itself received more bandwidth so we're switching to will link with more bandwidth the packets got taller and

1:14:58

narrower they shifted their shape to fit in the new pipe and so something that I

1:15:04

think is really confusing to people when they see these diagrams is that wait a minute when I change the link that I'm

1:15:10

using the packets themselves also change shape and yes that's true they change shapes because they fit in the pipe in a

1:15:17

different way in particular more dots can be stacked and so they get taller

1:15:23

and they get narrower because it takes less time to send them through the pipe the other thing that I think is not

1:15:28

totally intuitive is the transmission delay is the width of the packet so the

1:15:34

width of this packet tells me the transmission delay that is how long does it take to shove this packet into the

1:15:40

pipe and what this picture is showing you is that if you increase the bandwidth now that they can March in t

1:15:46

instead of stacks of five the transmission delay got shorter and that's represented by the fact that the

1:15:51

packet got less wide I know I just said a lot of words at you

1:15:58

this will probably take a little bit of playing around with the demos and watching the animations to make sense if

1:16:03

the dots don't make sense I really just care about the shape of these rectangles but maybe they helped maybe they didn't

1:16:09

complain at me in the comments if you didn't like this but you can't say I didn't try I drew

1:16:15

all the diagrams any questions on this by the way it is kind of a funky topic when I

1:16:21

saw this I had for the first time I had no idea what the pipes look like when I drew the dots in they made a little bit more sense to me but maybe

1:16:28

not but the key idea I think is really confusing is really just the fact that transmission delay is actually the width

1:16:33

of the packet not immediately obvious and the fact that it gets uh shorter as the packet gets

1:16:40

taller okay an attempt was made but let me know on ad or elsewhere if you find

1:16:46

this confusing we can talk about it somewhere

17 of 32

Overloaded Links

Lecture 3, CS 168, Spring 2026

Links

Bandwidth and�Propagation Delay
Pipe Diagrams
Overloaded Links

Brief Preview of the Semester

18 of 32

Packet Switching at Routers

Recall: Routers receive packets, and forward them toward their destinations.

For simplicity, consider 2 links with incoming traffic.
For simplicity, consider sending all outgoing traffic out of 1 link.

Router

so let's talk about that so ultimately we talked about

1:17:13

routers roughly and we're going to talk about them a lot more in this class but at a very high level routers receive

1:17:19

packets and then pick a link to forward them closer to their destination the router says I can't reach the

1:17:25

destination but if I send it to my buddy over here they're going to get this packet closer to the destination for you

1:17:32

so routers ultimately receive packets from links and send them out of links so here's an example where the router has

1:17:37

two incoming links so for Simplicity we'll just assume these two links are being used to send traffic inwards in

1:17:44

reality links might be bidirectional here we're assuming these links are just used for inputting data and then we'll

1:17:50

assume it has just a single outgoing Link in other words this router is going to forward all the packets to the right

1:17:56

in reality there could be multiple outgoing links for now let's just assume one so let's see what happens as we go

1:18:03

through a time and these are pipe diagrams by the way you see these little rectangles they're packets and this

1:18:08

larger rectangle is the pipe itself so we're already using pipe diagrams which is kind of cool so this is a frozen

1:18:14

Moment In Time lots of packets are streaming into the router and the router's goal is to get them all out on

1:18:19

its only outgoing link that's the goal of this particular router so if I look at this type diagram

19 of 32

Packet Switching at Routers

Recall: Routers receive packets, and forward them toward their destinations.

For simplicity, consider 2 links with incoming traffic.
For simplicity, consider sending all outgoing traffic out of 1 link.

Router

B1 is the closest

1:18:26

to the router it's going to get there first and the router forwards it out of the link and all the other packets make

1:18:32

their way toward uh the router so they all move toward the router a little bit what comes next well packet A1 is about

1:18:39

to enter the router so at the next time step the router receives A1 sends it out out of the outgoing link and all the

1:18:45

other incoming packets take a step closer okay good and then D1 takes a

1:18:50

step over outwards toward its next top okay good at the next step A2 shows up

1:18:56

great and it gets sent out and then at the next step B2 enters and it gets sent

1:19:02

out A3 enters get sent out B3 and A4 worked out just line at every given time

1:19:08

step the router only had to process one packet and send it out so this router was not overloaded it was able to

1:19:14

successfully handle all of the packets from the incoming links with no problem so the traffic wasn't too heavy the

1:19:20

router was able to process and forward all of the packets and careful viewers might have noticed I think I messed up

1:19:26

this animation but pretend you didn't see it the important thing was just packets coming in and going

1:19:32

out I'll fix it later okay here's an example where the router was going to have some overload

20 of 32

Transient Overload

What happens if two packets arrive at the router simultaneously?

Can't process both at the same time! Router must queue one for later.
When there are no incoming packets, router can drain the queue.
This is called transient overload, and it's fairly common.

Router

Queued:

so take a look at

1:19:39

this picture the router has two packets arriving at the exact same time so in this pipe diagram Frozen in Time A1 and

1:19:47

B1 are both about to arrive at the router at the same time they're right there next to the router and on the next

1:19:53

time step they're both going to arrive well that's a problem because this router can't handle two packets at once

1:20:00

can only handle one packet at a time it looks at the packet thinks about where it needs to go forwards the packet so if

1:20:06

this router can only handle one packet at a time what happens if it suddenly gets two at once well it's a problem and

1:20:12

the solution is the router is going to keep a que and the que basically says here are some packets that I've received

1:20:18

but I have not processed so I'm going to save them for processing later and that's actually totally fine happens all

1:20:25

the time in the internet

21 of 32

Transient Overload

What happens if two packets arrive at the router simultaneously?

Can't process both at the same time! Router must queue one for later.
When there are no incoming packets, router can drain the queue.
This is called transient overload, and it's fairly common.

Router

Queued:

22 of 32

Transient Overload

What happens if two packets arrive at the router simultaneously?

Can't process both at the same time! Router must queue one for later.
When there are no incoming packets, router can drain the queue.
This is called transient overload, and it's fairly common.

Router

Queued:

23 of 32

Transient Overload

What happens if two packets arrive at the router simultaneously?

Can't process both at the same time! Router must queue one for later.
When there are no incoming packets, router can drain the queue.
This is called transient overload, and it's fairly common.

Router

Queued:

24 of 32

Transient Overload

What happens if two packets arrive at the router simultaneously?

Can't process both at the same time! Router must queue one for later.
When there are no incoming packets, router can drain the queue.
This is called transient overload, and it's fairly common.

Router

Queued:

25 of 32

Transient Overload

What happens if two packets arrive at the router simultaneously?

Can't process both at the same time! Router must queue one for later.
When there are no incoming packets, router can drain the queue.
This is called transient overload, and it's fairly common.

Router

Queued:

Router

Queued:

Router

Queued:

26 of 32

Packet Switching at Routers

Persistent overload: Not enough capacity to handle the incoming packets!

Queue won't help us. If the queue fills up, the router must drop packets.

How do we solve persistent overload?

Operators can detect the overload and (manually) upgrade the link.
Routers can tell the senders to slow down.

Router

Uh oh...

but sometimes the router cannot handle

5:02

all the incoming load so if the two pipes that are incoming look like this well this router is doomed it's not

5:09

going to be able to handle all of these packets no matter how much it tries to

5:14

put packets in a queue it's just not going to have enough bandwidth to send out this many packets over a single link

5:22

so this router is in trouble the que is going to build up and build up and eventually the queue itself is going to

5:28

exceed some limit and become to full and at that point this router simply has to give up and it's going to start dropping

5:35

packets which means it receives a packet and just ignores it doesn't get forwarded the packet just gets lost and

5:42

stuff like this by the way is why we said that the internet has best effort at layer three it's because we design

5:48

routers like this and the way that we design routers which is that we allow them to drop packets in cases like this

5:55

is consistent with our design that we said routers only have to offer best effort service so it's a nice case of

6:02

the design matching the implementation because we said that the Internet only provides best effort well then this

6:08

router is allowed to drop packets if it can't handle them because the internet is best effort so you could have a que

6:16

but the que is not going to help you if you try drawing this out with a que the que itself is going to get packed and to

6:22

full and eventually some of these later packets are just going to get dropped so here we call this persistent overload

6:28

because it's not the case that the router temporarily had a little bit too much to do but later it was able to

6:34

clean out the queue this is the case where the queue is never getting clean we just don't have enough capacity this

6:40

router is just not powerful enough or doesn't have enough processing power doesn't have enough outgoing bandwidth

6:47

to process all the packets that are incoming so this is a problem of not enough capacity it's not a problem of a

6:54

temporary overload that gets solved this is a persistent problem that's why people call persistent overload so how

7:01

do you fix this turns out there's not really a great answer one possible answer is the router itself logs

7:09

somewhere for its operator the person operating this router hey I am not able to send out all the packets I have been

7:15

dropping a lot of things lately you might want to consider upgrading me to a better model give me some more

7:21

processing power connect me to some more links so that I can actually handle all the packets but that's a manual process

7:28

it's not something that the router can just automatically do routers don't upgrade themselves automatically someone

7:34

would actually have to come in and rewire this router or install a better one to handle this kind of load and

7:40

something else we'll see later in the semester is this router might actually be able to send a packet backwards to

7:46

the sender and tell the sender you are sending me too much you need to slow down because I can't handle this kind of

7:53

load and that's something we'll spend a lot of time on when we talk about congestion control but for now I just

7:59

wanted to get the point across that routers take in incoming packets they forward them sometimes there is

8:04

transient overload and sometimes there is persistent overload which we will try and solve a lot

8:12

later any thoughts on this stuff

27 of 32

Packet Queuing and Life of a Packet

Queues introduce extra delay.

Packet delay = Transmission Delay + Propagation Delay + Queuing Delay.

Life of a packet:

Sender puts payload in a packet, adding headers.
Packet travels along a link.
Packet arrives at a router. Router forwards packet to the next hop.

Packet might be queued or dropped.

Repeat the last step until:

Packet reaches destination.
Packet is dropped.

8:18

okay so we actually have to go back now and revisit what a packet does when it

8:24

travels from its source to its destination because remember earlier we said that you send a packet the delay of

8:31

the packet comes from two sources one is the transmission delay that is how long does it take for all of the bits to

8:38

March into the pipe and the propagation delay is how long the pipe is how long does it take for the bits to travel

8:44

across the pipe but there's actually a third term that we've now introduced that we previous previously had not

8:51

thought of which is queuing delay because it could be the case that this packet travels multiple hops to its

8:58

destination and some of the intermediate routers trap the packet in a queue for some time before the packet can get

9:04

forwarded so that actually could introduce additional delay into the time

9:10

it takes to send a packet from a source to a destination so we already saw these

9:15

two terms those are in terms of the link that you have the bandwidth the propagation delay and now we have a

9:21

third term which is the queuing delay and that comes from routers that might have to put this packet in a que so in

9:28

total if you think about what does a packet do from the moment it's created to the moment it's received well the

9:34

sender is the one that creates the packet it wraps the packet around a bunch of headers like we've seen before

9:40

and then it sends the bits of the packet along a link and how long it takes to send the packet along the link depends

9:47

on those two terms eventually the packet arrives at a router and the router has

9:52

to forward the packet closer to its destination so the router says I'm not the Final Destination but the final

9:58

Destin is that way so send it that way so the router is going to forward the packet

10:04

and in doing so the packet might have to wait a little bit in the queue or if this router is totally overwhelmed maybe

10:12

that packet just gets dropped that's also an option and then this just repeats over and over again we get to

10:17

the next router there might be some queuing time the router might drop it and if it doesn't drop then that packet

10:24

gets forwarded to the next router that router cues it for a little bit maybe maybe drops the pack pet forwards it

10:30

again and this repeats over and over again until either the packet reaches its destination because all the routers

10:36

along the path correctly forwarded the packet or the packet got dropped along the way in which case it's not reaching

10:43

its destination the end host will have to do something about that so roughly speaking that is what a packet does from

10:50

the moment it's created to either the moment it drops or the moment it reaches its

10:57

destination any thoughts on this

28 of 32

Brief Preview of the Semester

Lecture 3, CS 168, Spring 2026

Links

Bandwidth and�Propagation Delay
Pipe Diagrams
Overloaded Links

Brief Preview of the Semester

29 of 32

Brief Preview of the Semester

Lectures 1–3: Networking Principles.

Layering and headers.
Design principles.
Links, life of a packet.
Project 1: Traceroute.

Lectures 4–9: Routing (Layer 3).

Routing: How do routers know where to forward packets?
Addressing: How do we address end hosts?
How do you build an industrial-strength router in hardware?
Project 2: Routing.

12:07

you've already done the first three lectures those were our basic networking principles we talked about the layers of

12:14

the internet we talked about how packets get wrapped in headers as they work down the stack and unwrapped as they work

12:20

their way up we talked about all those design principles for why the internet is built the way that it is the end to

12:26

end principle d multiplexing the narrow waist we talked about statistical

12:32

multiplexing and sharing of resources and last time we talked about what a link looks like how you measure the

12:38

quality of a link and what a packet does when it travels through the network so once you have these three lectures

12:44

you're actually all set to start on Project one and project one really just

12:49

reminds you about all of these principles and asks you to build a neat little networking utility called trace

12:55

route so hope you're enjoying that so the next six lectures starting today and

13:01

running for the next six lectures we are now going to zoom in on routing for a long time and this happens at layer

13:08

three so you can think about Layer Three is the one that connects all the routers and the hosts to each other on the

13:14

entire global internet and we're going to answer a question about routing which is how do routers actually know how to

13:20

forward packets when I receive a packet how do I know that okay this packet is for Bob and Bob is that way or this

13:27

packet is for Alice and Al is that way how does the router know where everyone is that's the fundamental question

13:33

behind routing we're going to spend a lot of time answering that we'll also along the way see how you actually

13:39

assign addresses to end hosts turns out the network doesn't call them Alice and

13:44

Bob we actually give them addresses and we'll talk about how you assign those and as a fun little Topic at the end

13:50

we'll see how you build an industrial strength router so we'll open up a router and see what all the hardware

13:56

components are and in this section you'll get a project to do which is all about routing so that's this entire unit

14:04

I think this is most of the stuff on the midterm but don't quote me on

14:09

that okay and

30 of 32

Brief Preview of the Semester

Lectures 10–13: Reliability (Layer 4).

TCP: How do end hosts communicate reliably?
Congestion control: How do we ensure end hosts don't overload the links?
Project 3: Transport.

Lectures 14–15: Applications (Layer 7).

DNS: How do we map names to addresses?
HTTP: How do we build applications on top of the network?

Lectures 16–17: End-to-End Picture.

ARP and DHCP: What happens when you join the network for the first time?
NAT: How do we make sure there's enough addresses for everybody?
TLS: How do we secure network connections against attackers?

then after that after the midterm maybe we switch into layer four

14:15

and we start thinking about how do you actually build a reliable protocol so we showed you that little super simple Bob

14:21

sending 10 packets reliability protocol and some people pointed out there are some bugs in that that we didn't really

14:27

address and you're right a real solid state-of-the-art reli reliability protocol will take us four lectures to

14:34

build so we're going to spend two lectures building TCP to ensure reliability and then we'll spend two

14:40

more lectures talking about congestion control so that we ensure that the NH host don't overload the links and these

14:47

are associated with the third project which is all about transport and implementing

14:52

TCP and then after that two lectures at layer seven so we're basically moving up the stack and at layer seven there

14:59

there's two applications that we'll talk about one of them is DNS one of them is HTTP I won't talk about them any further

15:05

here because you'll get them a lot later but there are examples of things that we can build on top of the network to make

15:12

everything work and once we've traveled across all the layers in lecture 16 and 17 we'll go back and clean up all the

15:19

little missing pieces that we haven't really touched yet to form what we call the end to endend picture so by lecture

15:26

17 you will finally get the ultimate picture of what exactly happens when I send a packet from point A to point B

15:32

all of the missing pieces will get filled in we'll go through all these protocols that didn't really fit anywhere else but have to be covered and

15:40

we'll also spend a little bit of time at Layer Two and everything will be connected up so we'll spend a lot of time at layers three four and seven and

15:47

once we do that we'll Circle back and tie it all together in lectures 16 and 17 so that's the next part of the

15:57

semester

31 of 32

Brief Preview of the Semester

Lectures 18–21: Datacenters.

How do we build a network to connect servers in high-performance datacenters?
SDN: Can we centralize control to improve performance?
Host networking, RDMA: How can we optimize performance at the end hosts?

Lectures 22–23: Beyond Client-Server.

Multicast: How do we support group communication (e.g. Google Docs)?
Collectives: How do we design networks to support AI training?

Lectures 24–25: Wireless.

How do we design wireless communication at Layers 1 and 2?
How do we design cellular networks?

okay and then near the end we'll have some other topics that didn't

16:02

really fit in the networking stack but are still really important so in lectur

16:08

18 through 21 we're going to talk about data centers so this is a pretty new

16:13

topic it's pretty state-of-the-art and we're going to talk about building networks to connect up servers at a high

16:18

performance data center so to give you a little preview you can imagine I don't know Facebook or YouTube is probably

16:25

running this big building full of computers and those computers have to talk to each each other how do you build

16:30

networks in that special context lectures 18 19 20 and 21 will tell you

16:35

all about that that's pretty cool and then lectures 22 and 23 these are even newer additions to the class they're

16:42

called Beyond client server it's what we called it and basically we'll think about some newer applications at the

16:48

internet such as like Google Docs where you want to communicate in a group and also how do you use networks to support

16:55

AI training that's pretty cool this I think is the newest lecture we've made apparently it's a Super Hot Topic in

17:00

research so look forward to that and then lectures 24 through 25 as a bit of a dessert will give you a quick tour of

17:08

Wireless so it turns out designing Wireless Communications comes with it comes with its own set of challenges so

17:15

we'll take a look at what it means If instead of thinking of links as wires we think of them as Wireless Communications

17:22

so you get one lecture on wireless communication one lecture on cellular networks like how does your phone access

17:27

the internet if even though it's not connected to anything we'll talk about that and we'll be all done so that's the

17:34

overview of the semester a lot of the things that we're talk going to talk about you've already gotten a little preview of in the three lectures so far

17:43

but we'll just spend a lot of time digging into them and then at the end you get all these neat applications and

17:49

things that are pretty hot now and active areas of research which is pretty

17:54

cool any thoughts on the brief preview

18:01

yeah data centers seem cool I hope uh I agree they're pretty cool I hope you think so as well when we get to

18:10

it okay so to

32 of 32

Summary: Links

Packet Delay = (Packet Size / Bandwidth) + Propagation Delay + Queuing Delay��
Routers experience transient overload if packets arrive simultaneously.�Solution: Packets get queued for later.
Routers experience persistent overload if there's insufficient capacity.�Queue gets full, and packets get dropped.

Transmission Delay

Bandwidth

Propagation Delay

Capacity = Delay × Bandwidth

Transmission Delay

Bandwidth: 1,000,000 bps

Delay: 0.001s

t = 0s

0.000001s

0.001001s

0.000800s

0.001800s

800-bit packet

Transmission Delay

Propagation Delay

Briefly summarize links we talked about this handy little formula

18:16

where we said the packet delay is the sum of the transmission delay that is how long it takes to send all the bits

18:22

across the wire plus the propagation delay how long it takes for a single bit to travel all the way from one end to

18:28

the other end plus the queuing delay in case packets have to wait at a Queue at an intermediate router or multiple

18:35

routers perhaps and we talked about two types of overload transient overload if a couple packets arrive at the same time

18:42

and we queue them and the queue drains or persistent overload where there's just not enough capacity to handle

18:47

everyone incoming and we also spend some time looking at two types of diagrams to help us analyze links we talked about

18:55

these timing diagrams where we draw time going down and and this allows us to check when a packet gets sent and

19:01

received and we also showed you the pipe diagram which shows uh the Link at a

19:07

frozen moment in time and from this you can actually derive some of the properties of the link itself such as

19:13

propagation delay transmission delay bandwidth so that's the summary of links

19:19

any final

19:26

questions