YT YouTube2Text

YouTube2Text → Transcripts → 4.2 What's inside a router? Part 2.

4.2 What's inside a router? Part 2. — Transcript

by JimKurose · 3,505 words · 535 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00[Music]
0:09well now that we've got a really good
0:11appreciation for the pieces of the
0:13router the input ports the output ports
0:15and the switching fabric we're going to
0:17dive down deep into the topics of packet
0:20scheduling and buffer management and
0:22we've seen how important these are with
0:24the Internet's best effort service model
0:26packet loss and packet delay have had a
0:28profound effect on what has to happen
0:30the transport layers and the application
0:33layers so now we're going to dive down
0:35deep into the topics of packet
0:37scheduling and buffer management and
0:39we'll take a look at how those can be
0:41used to control and also mitigate packet
0:43loss and packet delay well let's get
0:47started by first taking a look at input
0:49port queuing remember that we saw
0:51earlier that input port queuing can
0:53happen when the routers switching fabric
0:56is less than the combined rates of its
0:58incoming links in this case more packets
1:00can arrive in a unit time then the
1:02switching fabric can possibly move from
1:05the input side of the fabric to the
1:06output side and so queuing can occur on
1:09the input side a queuing phenomena
1:12that's unique to the input side of the
1:14switching fabric is what's known as head
1:16of the line blocking or hol end of the
1:19line blocking occurs when packets at
1:21different input ports want to go to the
1:24same output port if only one pack at a
1:27time can be transferred from an input to
1:29a given output port and if there are K
1:32packets that want to go to the same
1:34output port then K minus 1 of those
1:36packets are going to have to wait on the
1:38input side of the switch and if packets
1:41have to wait they can also block the
1:43packets behind them in their input queue
1:46from moving forward and this is what's
1:48known as head of the line blocking take
1:51a look at this example here where the
1:53colors of the packets correspond to the
1:55output port to which they're destined in
1:57this example say at time T we see the
2:00top and bottom input ports have a red
2:03packet destined to the upper output port
2:06in one clock deck the upper red packet
2:09is transferred from the input to the
2:10output side of the switch the blue
2:13packet in the middle it's also able to
2:15move from its input port to its output
2:17port the red packet at the bottom
2:20however is
2:21locked from moving to the read output
2:23port since the packet at the top was
2:25already transferred there and so the
2:27green packet behind this lower red
2:29packet experiences head of the line
2:31blocking let's now focus on the output
2:35port side since this is really where the
2:37action is and let's start by seeing why
2:40buffering is needed in the first place
2:42at this output port we have a link with
2:45transmission rate of our bits per second
2:47and let's say we have a non-blocking
2:49switch capable of delivering end times
2:52our bits per second to the output port
2:54now we can see why buffering occurs bits
2:58can be arriving at a rate of end times
3:00are but bits can only be drained or
3:03transmitted out at a rate of are
3:05whenever the arrival rate exceeds the
3:08departure rate the buffer will fill and
3:10since buffers are finite there may not
3:12be enough buffer space to store all of
3:14the packets that need buffering and
3:16packets will have to be dropped there
3:18simply isn't enough memory to hold all
3:20of the packets that need buffering so
3:22right here at the output port is where
3:25congestive packet loss occurs and you
3:27know it may be tempting to say well it's
3:30really the switch fabrics fault it's
3:32delivering packets too fast at a rate of
3:35end times are when the link can only
3:37drain at rate R so we should slow the
3:39fabric down but that's not really the
3:42cause of the problem is it think back to
3:44our earlier discussion of principles of
3:46congestion control the real cause of the
3:49problem congestion is that there are too
3:52many transport layer senders at the edge
3:54of the network sending too many packets
3:56too fast packets whose paths cross at
4:00this congested output port in the face
4:03of buffering and congestion there are a
4:05couple of decisions that'll need to be
4:07made at the output port first if there's
4:10not enough room for all arriving packets
4:12a packet drop policy will be needed to
4:14determine which packets are going to be
4:16dropped and if there are multiple
4:18packets in the buffer awaiting
4:19transmission a packet scheduling
4:21discipline will be needed to choose
4:23which packets among the many cute
4:25packets will be transmitted next we'll
4:28look at both drop and scheduling
4:30policies in just a second now there are
4:32a lot of really important idea
4:34that we just talked about here on this
4:36slide so make sure you've got it all
4:38it's really important well you might be
4:43thinking given buffering is such a big
4:46concern how much buffering should a
4:48router have and more to the point you
4:50might also be thinking well hey
4:52shouldn't it be a good idea to invest in
4:54a lot of buffering with a lot of
4:57buffering there'd be less packet loss
4:58since there'll be more buffers to
5:00observe the burstiness and packet flows
5:02having more buffering must be a good
5:04thing right well it might surprise you
5:07that even after 50 years the question of
5:11how much buffering is the right amount
5:12of buffering is still pretty much an
5:14unresolved issue there are some
5:16recommendations you could take a look at
5:19RFC 3439 and find a rule of thumb that
5:22says the amount of buffering should
5:24equal a typical RTT say a couple hundred
5:27milliseconds times the output link
5:29capacity there's also been more a recent
5:32theoretical research that assumes that
5:34transport layer senders are generally
5:36independent of each other and recommends
5:39dividing the RFC 34:39 amount of
5:42buffering by the square root of n where
5:44n is the number of flows crossing the
5:46link and that's a lot less buffering and
5:49while you might have the sense that
5:51large buffers will generally result in
5:53less loss and you could be right
5:55large buffers do have a downside large
5:58buffers mean larger delays and larger RT
6:01T's large delays are bad for gamers and
6:04for interactive teleconferencing users
6:06where tens of milliseconds really do
6:08matter but maybe even more importantly
6:11large RTT delays mean that TCP senders
6:15will be slower to detect and therefore
6:17react to congestion you might recall
6:20that when we studied delay based
6:22congestion control we encountered the
6:24saying that we want to keep the
6:25bottleneck link just full enough to keep
6:28the link busy but no fuller but that was
6:31from the perspective of the sending
6:33hosts when we think about the amount of
6:35buffering we really do want buffers to
6:37absorb short term statistical
6:39fluctuation in packet arrival rates and
6:42to keep the link busy but not to have so
6:45much buffering that congestion control
6:47action times become slow and sluggish
6:50well buffering sort of like salt and
6:52cooking you've got to find the right
6:54amount
6:54just the right amount makes things
6:56better but too much can really ruin
6:58things well who would have thought that
7:01buffering and queuing at an output port
7:03could actually be so complicated and so
7:06subtle and you may ask yourself why is
7:08that and it's really because it's here
7:11at an output port buffer that the global
7:15behavior of potentially thousands of
7:17active senders worldwide are converging
7:20as their flows all pass through the
7:22single output link we see the
7:25convergence of global internet scale
7:27behavior at this one location deeply
7:30inside the internet that's pretty cool
7:34well we're next going to move on to the
7:37mechanisms for buffer management and
7:39packet scheduling and will find it
7:41useful to think of an output port
7:43abstractly as a queue as shown here of
7:46course we're all familiar with queuing
7:48systems in our daily lives banks at
7:51buses at bus stops at food stores at
7:54metros and many other places think about
7:57how many cubes you've been in today
7:59packets arrive to the queue they wait
8:02for service and they're eventually
8:03selected for service receive service and
8:06then leave the queue the link layer
8:08functions as the server when a packets
8:10bits are being transmitted over the
8:12outgoing link that packets in service if
8:16an arriving packet emerges from the
8:17switching fabric to find there's no free
8:19buffer space either that packets going
8:21to be dropped and that's known as tail
8:24drop or an already queued packet could
8:26be removed from the buffer and dropped
8:28to make room for this newly arriving
8:30packet say according to some kind of
8:32priority mechanism for example there
8:35might be a policy to drop low priority
8:37packets say carrying end-user TCP
8:40traffic rather than high priority
8:42packets say carrying Network management
8:44in control packets for the ISP as we
8:48also learned when we studied Network
8:50assisted congestion control a buffered
8:53packet may also be marked with a
8:55congestion indication to signal that the
8:57link is becoming congested we learned
8:59earlier that for the
9:01internet's explicit congestion
9:02notification ecn mechanism to bits in
9:06the IP header type of service field are
9:08used for ecn marking will see these bits
9:11in the IP datagram header in the next
9:13section when we study ipv4 but it's here
9:17at the output ports and where congestion
9:18occurs that these bits are going to be
9:21set we can now look at several packet
9:24scheduling disciplines that are used in
9:26practice under first come first serve
9:29scheduling packets are transmitted
9:31simply in the order in which they arrive
9:32to the output port we're all familiar
9:34with first-come first-serve queuing I'm
9:36guessing it's what people do the most we
9:39all join the back of the queue and
9:40customers are served from the front of
9:43the queue
9:43same thing with packets
9:46we're all familiar with priority queues
9:48you get that with Airlines platinum
9:50diamond gold silver or bronze class of
9:53service they all sound pretty fancy and
9:55great but you definitely rather be
9:57platinum than bronze and I think we all
9:59probably have an intuitive understanding
10:01of how priority disciplines work having
10:03been in the lower priority class of
10:05service and seeing later arriving people
10:08in higher priority classes getting
10:10service before us under priority
10:13scheduling packets arriving at the
10:15output link are classified into priority
10:17classes on arrival at the queue as shown
10:20here where we have a high priority red
10:23class of traffic and a lower priority
10:24green class of traffic the priority
10:27queueing discipline will transmit a
10:29packet from the highest priority class
10:30that has a non-empty queue that is has
10:34packets waiting for transmission the
10:36choice among packets in that same
10:37priority class is typically done in a
10:40first-come first-serve manner this
10:42animation shows packets arriving from
10:44the top entering service according to a
10:46priority discipline and then leaving the
10:49queue in this example packet one arrives
10:52finds the queue empty and enters service
10:55while packet one is in service packet
10:58two and three arrived when packet one
11:01finishes both packets two and three are
11:03buffered but packet three is chosen for
11:06transmission even though it arrived
11:07after packet two since it has higher
11:10priority than back at two and so on
11:18well we've now learned about the
11:20priority queuing mechanism but you may
11:22still be wondering what is it that
11:25defines a priority class in the first
11:27place how is it determined what goes
11:29into priority class 1 or priority class
11:312 for example and this is actually
11:33determined by the network operator by
11:36the ISP the ISP may decide that well
11:39network management traffic's really
11:41important it's the highest priority
11:43class voice-over-ip gets higher priority
11:46than email and so on and you remember
11:49that by looking at the transport layer
11:51port numbers one can determine what type
11:55of traffic is being carried by that data
11:57graph now traffic type is one way in
12:01which priorities could be determined
12:02another way might be on the basis of
12:05source or even destination addresses so
12:09here's another possible way to classify
12:11traffic into priority classes imagine
12:14that a company is willing to pay an
12:16internet service provider to give its
12:18packets better service packets are less
12:21likely to be dropped its packets suffer
12:24less delay as a result if it's a search
12:26company its search results get to users
12:28faster if it's voice over IP the voice
12:31is more responsive if it's streaming
12:33video there's less spinning meals well
12:36we've got the scheduling mechanisms to
12:38do that whether or not a company is able
12:41to pay for that kind of better service
12:43actually gets us into the topic of
12:45what's known as network neutrality we're
12:47going to cover that in just a second but
12:49first let's wrap up by looking at a few
12:51more scheduling disciplines so we've
12:55seen first-come first-serve and priority
12:57scheduling under round-robin scheduling
12:59packets are assigned to classes as with
13:02priority scheduling however rather than
13:05there being a strict service priority
13:07among classes a round-robin scheduler
13:10alternates service among classes for
13:13example a round-robin scheduler would
13:14choose a packet from class 1 followed by
13:17a packet from class 2 followed by a
13:19packet from class 3 and so on and if
13:22there's no packet of a given class the
13:24scheduler moves on to the next class in
13:26the schedule
13:28a generalized form of round-robin
13:30queuing that's been widely implemented
13:32in routers and practice is known as
13:35weighted fair queuing wfq light priority
13:39and round-robin scheduling arriving
13:41packets are classified and queued in the
13:43appropriate per class waiting area we
13:46see here red green and blue packets
13:49waiting for their service a weighted
13:51fair queuing scheduler schedules classes
13:53in a round-robin like manner first
13:56serving class 1 then serving class 2
13:58then serving class 3 and then assuming
14:01there are just three classes repeating
14:03that service pattern weighted fair
14:05queuing differs from round-robin
14:07in that each class can receive a
14:10different amount of service in any
14:11interval of time and here's how it works
14:14ideally each class of packets I has a
14:17weight W sub I let's assume that all of
14:21the weights the sum of W J say sum up to
14:241 under weighted fair queuing during any
14:27interval of time during which there are
14:29class I packets to send class I will
14:32then be guaranteed to receive a fraction
14:35of service W sub I that means if the
14:38link has a rate R then each class of
14:40service will get a guaranteed minimum
14:43amount of bandwidth W sub I times R and
14:46so we can see how weighted fair queuing
14:49allows some type of a bandwidth
14:51guaranteed to be made on a per class
14:53basis network neutrality is an area
14:58where our technical interests in
15:00computer networking intersect with
15:02social political and economic
15:03considerations well we've already seen
15:06the mechanisms for sharing resources but
15:10what about the social political and
15:11economic considerations about how those
15:14resources are shared let's take a look
15:18network neutrality is about the laws and
15:20policies that govern how an Internet
15:23service provider can use the traffic
15:25control mechanisms that we've just
15:26learned about packet scheduling in
15:28particular to control network traffic so
15:31what are some of the questions that
15:33network neutrality addresses well it's
15:36about a number of different things it's
15:38about free speech for example cannon
15:41Espie refused to carry some types of
15:43traffic for example certain types of
15:45news or political opinion it's also
15:48about encouraging innovation and about
15:51encouraging competition for example must
15:54an isp give all companies big and small
15:57equal treatment of their traffic as you
16:00probably know different countries have
16:02been adopting different stances with
16:04respect to these questions we're going
16:06to take a look at what's happening in
16:07the united states since this is well
16:09documented and has all been playing out
16:11pretty publicly our textbooks got some
16:14interesting references about net
16:16neutrality worldwide that you might want
16:18to take a look at in 2015 the United
16:21States Federal Communications Commission
16:23order on protecting and promoting an
16:26open Internet defined three clear bright
16:29line rules associated with network
16:32neutrality let's take a look at what
16:34they are the first bright line rule is
16:37no blocking and here's what it says it
16:39says that an isp quote unquote shall not
16:42block lawful content applications
16:45services or non-harmful devices subject
16:49to reasonable network management in
16:51quote now there's a lot packed in there
16:54the word lawful and applications
16:57services and devices well this rules
17:00about blocking traffic and there
17:02actually was a case involving an ISP
17:05that had a practice of blocking its
17:07customers from using vonage which is a
17:09voice over IP service that competed with
17:13this is p's own telephone service that
17:16would not be allowed and notice the
17:18phrase subject to reasonable network
17:21management will cover network management
17:23when we cover the network layer control
17:25plane but note here that it is allowable
17:27to block traffic for network management
17:29purposes say if the networks been
17:31degraded and then only trickles of
17:33traffic can get through then it's best
17:35that network management traffic be able
17:37to get through of course the question of
17:39what reasonable network management is is
17:41left open to interpretation
17:43the second bright-line rule is no
17:47throttling that is an isp quote unquote
17:50shall not impair or degrade lawful
17:53Internet
17:53effect on the basis of Internet content
17:55application or service or use of a non
17:58harmful device again subject to
18:01reasonable network management note here
18:04the words impaired or degrade there was
18:07a case not too long ago where an ISP was
18:10judged to be interfering with BitTorrent
18:12peer-to-peer traffic and it was doing
18:15this by internally creating and sending
18:17TCP reset packets to BitTorrent client
18:21and servers executing at the end host
18:23this caused the host to close their
18:25BitTorrent connections basically the ISP
18:28was closing the TCP connection
18:30underneath the BitTorrent application
18:32whose traffic it really didn't want and
18:35then finally there's the bright-line
18:36rule of no paid prioritization
18:43this means for example that video
18:45streaming traffic from all video
18:47streaming service providers must be
18:49treated the same for example that one
18:52streaming video service provider cannot
18:54pay to get its packets better service on
18:57their way to the customer and of course
18:59we've seen how this can be done from a
19:01technical point of view via priority
19:03queuing well you might ask why no paid
19:06prioritization since paying for a
19:08priority service seems well almost like
19:10a fact of life at least here in the
19:12United States well one of the arguments
19:15is that if say a video streaming service
19:17provider can pay for better service and
19:20if that successful incumbent the
19:23existing service provider can pay a lot
19:25then this introduces a high barrier to
19:28entry for new competitors and of course
19:30some countries want to encourage market
19:33competition but there are counter
19:35arguments to this claiming that creating
19:37additional revenues for an ISP by having
19:40paid prioritization is a good thing from
19:43a competitive point of view since that
19:45makes the ISP marketplace more lucrative
19:47and so more companies will want to
19:49invest in the ISP market or ISPs will
19:52want to invest more in their
19:54infrastructure and then finally there
19:57are laws going back almost a hundred
19:59years that have regulated the telephone
20:01network as a telecommunications service
20:04provider but there's much less
20:06regulation of information service
20:09providers so what is an ISP is it a
20:12telecommunication service provider or an
20:15information service provider well it
20:17turns out from a regulatory standpoint
20:19the answer to this question matters a
20:22lot in the US but the answer to this
20:25question has really not yet been finally
20:27determined
20:29well these bright-line rules are from a
20:312015 u.s. FCC order more recent FCC
20:36orders have actually rewritten much of
20:38that 2015 order
20:40so until laws are written and until
20:42there's further litigation and case law
20:44adopted I think it's fair to simply say
20:47that the situation continues to evolve
20:49and I think that's true in many
20:51countries it's interesting that we've
20:54had the ability to do
20:55prioritization since the internet first
20:57became public nearly 30 years ago so
21:00although the Internet has a strong
21:02technical foundation as we've seen three
21:04decades later our social political and
21:07economic policies governing this
21:09creation that have not yet been fully
21:11defined or agreed upon well that wraps
21:15up our discussion of packet scheduling
21:17and packet buffering and also what I
21:19hope was an interesting sidebar into the
21:21topic of network neutrality and more
21:23generally it wraps up our discussion of
21:26what's inside a router remember we also
21:28looked at input ports output ports and
21:30switching fabrics coming up next we're
21:33going to take a look at the Internet
21:34Protocol ipv4 so stay tuned for that
21:50you
21:52[Music]

About this transcript

This page contains the full transcript of 4.2 What's inside a router? Part 2. by JimKurose, generated from the public captions YouTube serves with the video. The transcript has 3,505 words across 535 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.