Task ID #eb8d0f6c-6b50-4fcb-b39d-ae9357a4933c

SPEAKER: Hello and welcome back
to the second part of lecture 2

which is about the transport layer.

The transport layer segments application
data into transportable chunks

for transmission and also reassembles
segments as required

on the receiver side
the transport layer uses port numbers.

We also refer to those as ports
for short

to track individual
conversations and identify applications.

It is important to not confuse
these port numbers or ports

with physical ports on network devices
such as switches or routers.

Unfortunately we use
the same term for both

but based on the context
it's it's usually clear

what is meant or what
it is referring to.

The transport layer provides
reliability if required.

Well it depends on the kind of
transfer protocol that is used

and we do have different transport
layer protocols

so we can cater to different
requirements of application.

And since the transport layer
is responsible for transporting data

from the source to the destination

we also often refer to it
as an end to end concept.

Alright.

A very important concept on
the transport layer is port numbers.

So port numbers don't exist physically.
It's not a physical port.

They are a logical concept
used by operating systems

for the identification of
different applications.

Ports are identical but some
are actually recognized

as specific applications for example.

We talked about this in the first
part of the lecture DCP port 80

is recognised as a HTTP
port 53 three can be UDP or DCP

to recognise it's DNS and so on

Some applications can also have
multiple port numbers

for example HTTP can also use
other port numbers such as 8080.

And down here in the example you,
so if you figured it out

Here you see two or more examples.

So for electronic mail we have
port 110 for example

if we use the proper three protocol
and Internet chat

Internet chat application might use Port 531.

OK, and the port numbers they are actually
encoded in the transport layer headers.

The port numbers are sixteen
bit integer values.

So the range is 0 to 65,535

and this range is actually separated
into three different regions.

So three classes of ports.

We have what's called
the well known ports.

Those are the ports from 0 to 1023.

They're used for common services
and applications.

So HTTP port 80 is one example
port 53 for DNS is another example

or SDP we have port 25,
it's well known port for that protocol

Then above that range
of well-known ports

we have the range of registered ports
which range from 1024 to 49,151

So those are ports for less common
use services so applications.

Couple of examples here,
so OpenVPN uses Port 1194

CIP which is used in the context of
voice over IP uses port 5060.

And above that range
we have what's called

dynamic or private ports so all the ports,
49,151 until the end of the range.

They're dynamic ports and they're
used for client initiated sessions.

So these ports are dynamically
assigned to client applications.

And if you want to know
more there's a full list available

you can go to that Wikipedia page.

Alright, so here's another example
on the slide,

So in this example we have clients that
use private ports to initiate sessions.

And we have some uh
applications you're running on

well known ports and...

Yeah. Keep in mind the source port does
not need to match the destination port.

Some protocols where that is
the case or maybe the case

many probably from applications
that are peer to peer applications

but in general the source code
does not need to match

destination port and is often different.
In this example down here

we have one server that runs an HTTP
server port 80

and SMCP server port 25,
and we have two clients

client one on the side,
client two on the other side

and a client who makes an HTTP
request to the server

and it picks a random
port out of this dynamic range

which is here in this example port
49,152.

And then of course the HTTP request
must be sent to the port

on which the server application
is listening

and that's port 80 of course
and the server responds.

So we assume that that HTTP request
goes to your server

and the server responds.

The server response obviously
then comes from source port 80

and it goes to the clients port.

So the destination port
will be 49,152

And basically the same thing
happens over here with clients two

who wants to send an email.

The client has selected a
dynamic port here of the range

port 51152 and for the request
the destination port is the port,

the well known port of
the SCDP so port 25

and then when the response
comes back from the server

the response comes from port
twenty five and it goes to

that dynamic port that the client
put in the source profile

of the request which is Port 51152
so hopefully this makes

the concept of dynamic ports
and well-known ports clearer.

So let's move on to the transport
layer protocols that we will discuss.

In this part of
the lecture we will talk about

the two most common transport
layer protocols

the Transmission Control Protocol, TCP
and the User Data protocol, UDP.

TCP is used when
the delivery of data must be reliable

for example filed downloads,
for feature streaming ,

for loading web pages.
Address UDP is used when

the delivery of data must be timely
and doesn't need to be reliable.

So things like voice over IP,
video communications

especially real time sort of video
communications

they make use of UDP
as well as online games

where delay is to be avoided.

So in fact first person shooter games
they are usually based on UDP.

There are other transport protocols.

So it is actually not just TCP and UDP
but these other protocols

are not that widely used.

So two examples are Stream
Control Transmission Protocol, SCTP.

Actually SCTP is fairly
well used in the some of the

Telcom companies because
they use that as transport protocol

for signalling. That's just used
in the signaling network

but in a wider internet it
is not very widely used.

We also have the Datagram
Congestion Control Protocol

DCCP, another transport protocol
that's not very widely used.

So in the remainder of this part
we'll talk about a TTP protocol first

because it is way more complicated
and it's a lot more to say,

and then we'll talk about UDP which is
actually a fairly simple protocol

and then we'll end up with a little bit
of a comparison between the two

and for which type of applications
we should use TCP

and for which we should use UDP,
We'll discuss that at the end.

Alright let's talk about TCP.

TCP is a connection oriented protocol.

It means that the communications
between two devices

must be explicitly initiated
and terminated.

Not all transport layer protocols
are connection oriented

so UDP is not connection oriented.

So the first thing
to establish a TCP connction

is a handshake process that's known
as a three way handshake

and consists of three steps
or three segments that are sent around

and those are illustrated
in this figure here.

So clearly identify but three
numbers one two three.

So at a first step the initiator
of the connection which is

off the client will send
a SEE to the other side

of the server if the server
receive the SEE

the server will respond with the SYN AC
AC for acknowledgment

and then the handshake is completed
with another act sent by A here

over to B.

After those three packets
have been exchanged

the TCP connection will sort of
move into an established state

and then data can be exchanged
between the two sides okay.

So this is the way TCP
connections are setup.

On the next slide we'll
talk about how connections

are terminated so after a
conversation is complete

the connection is terminated
using either three or four steps.

These steps illustrated
this little picture down here.

And so what happens is when a
connection is terminated

one side that wants to terminate
will send what's called a FIN.

The other side will receive
the FIN and send it back.

And sometime later will
and also sent a FIN and finally

our station A here will send
an AC for that FIN

as received a B
and at this point in time here

the connection is
completely terminated.

So this is either a three way
or a four way process because

in many cases the AC here
is sent by B at the FIN

they can be combined
into a single segment.

So we actually only need three
segments, A will send FIN

B will send a combined AC FIN
and then A will send back AC.

But in some cases we actually may have
the full sort of four step process.

And on the next sort of
slide I will discuss why

we actually need a sort of slightly
more complicated process.

The fourth step process rather than
just having three messages.

So here's two questions for you regarding
the setup and tear down of TCP connections

Why do we actually need
a three way handshake?

isn't two handshakes sufficient?

So two handshakes as in
A to send a signal to B

and B responds back.

So why isn't that two way
handshake sufficient?

The reason this we need at least three
packets so that both sides

can be sure that the connection
is to be established.

Think about if we only had
a two way handshake.

So we only had this first packet
here and a second packet here.

Well there's no guarantee that
that AC here from B to A

actually arrives at , the AC could
be lost inside the network.

And so then we had the problem that
A would treat the connection as...

sorry, B would treat
the connection as established.

Assuming that the AC would arrive at A
but A actually never receives the AC

and A would treat the connection
as not established

because it hasn't received the AC

So only view that third packet here
going from A to B

both A and B can be sure

that the connection is in
an established state.

Second question down here is why
do we have full message.

Why do we have four messages
here down

rather than having only three messages.

And again the four messages
is not always happening.

We may have three messages
at times.

But why have four messages
in the extreme case, why is that?

Well simple answer is that TCP
actually supports half closed connections.

So it supports the case
where one side is closing

its side of the connection
but the other side still sending data

and this only works with a
four way sort of message tear down.

So in this example, imagine for example
that A wants to close

because A does not have any data
to send any more

so A sends a FIN which is acknowledged
by B with an AC

but B actually still has data that
needs to be sent to A

so rather than sending this FIN
immediately here

B will continue sending data
and then only when B has sent all the data

it will close its end
of the connection sending the FIN,

and then that is acknowledged by the AC
from A and then at that stage here,

the connection is fully closed.

So that the four message tear
down allows us to do

a half close on the connection basically

or close one side
and keep the other side open.

There is a little activity
on Cisco network and then a CAT here

about TCP connection
and termination process.

I will quickly show you but I want you
to do the whole activity

I'll leave that for you as homework.

Bear with me for a second.

So here is the activity.

The first activity is basically
the three way handshake

and you're meant to sort
of drag those boxes over here

into those fields here.

Until that sort of process
is correctly labeled.

And so it's pretty trivial.

So I mean A sends a SEE to B, right.

So then what it means is that we
have a SEE received here

and we can check for correctness.

So that's correct.

And then you can basically drag
and drop those other things over here

up to here.

Better learn how that handshake works,
you better memorize it,

and I think the other one,
so the second part of the activity

is about the termination session.

So again there's two boxes here
called FIN and AC

and you'd have to sort of
just drag those into those fields

to describe the termination process.

OK, let's go back to the lecture slides.

So now I want to talk about
the various sort of properties

that TCP gives us or gives
the application and TCP

has quite a bit of functionality
as you will see sort of.

The first thing is that TCP provides
in order, delivery of segments

to the application and it does
that based on sequence numbers.

So what happens is that sender here

divides that data up into the segments

and the segments are numbered
with sequence numbers

so example from one to six
and it sort of said in the first lecture

an IP that works

segments and packets that can take
different parts through the network.

So we'll have two possible
routes here

from the source to the destination
some segments here,

some segments or packets take this route,
but others might take this route.

So if they take different
routes then

they may actually arrive out of
order at the destination.

So in this case we receive segment 1, 2, 6
5, 4 and then 3

so the orders obviously jumbled up.

If we or the receiver here
if the stuck at the receiver would pass up

the segments in this jumbled up order
then obviously you can imagine that

the application but get
a lot of garbage basically

and couldn't interpret that data.

So whatever you're doing
like if you send an email

this would be completely garbled up.

So what TCP does is it
reorders the segments

back into the original order
based on a sequence

and as before it passes
the segments to the application.

So all the segments that are
passed to the applications

they are passed in the order
they were sent by the sender.

So there's no reordering
on top of TCP

or in other words applications
that use TCP

can be assured that segments or packets
are not delivered...

Not in the original order to
the receiving application.

The other thing TCP provides us with
is reliable transport

so the sequence numbers are used
in conjunction with

acknowledgement or Acs
or acknowledgement numbers

to provide reliable data
transport so all the data transmitted

using TCP must be acknowledged
and an acknowledgement is cumulative.

In TCP it means that it
also acknowledges

all the preceding segments that
were received

after the last acknowledgement that
has been received.

And receivers always acknowledge with
the next expected badge.

Keep that in mind.

So if we look at the example
over here we have a sender

and we have a receiver
and this example also

introduces us to the concept
of window size

we'll come back to that on some
of the following slides.

So window is basically the amount of
data that TCP can have in flight

and acknowledge and so in this
case it's 300 bytes.

And so this is why the sender
can send two

1500 byte segments here
over to the receiver.

and the receiver receive those two

and then the receiver will
send an acknowledgement

for both of these and you can
see that the acknowledged number here

is 3001, which is the next expected byte.

So the receiver has received all the bytes
for one to 3000.

The next expected
byte is 3001.

Well when the sender gets
acknowledgment the sender

sort of sends more segments
sends another two segments

down here with the bytes
3001 to 6000

and again the receiver will acknowledge.

both of these segments
here with one acknowledgement

and it will have the number
6001 because that is the next byte

the receiver expects
the sender to send OK.

Let's sort of go a bit more
into the details here.

So when segments are not
acknowledged within the time limit

so in the best case they
are acknowledged

like in a previous slide this is
when everything goes perfectly fine

but if things are not going that well
and segments are not acknowledged

within some time limit they need
to be re-transmitted by the sender.

Segments can be lost due to
network congestion

or interruptions to the medium.

If somebody I don't know,
takes out a cable or something like that

or falls in the hardware
of course.

Data received after a loss
is not acknowledged.

This is illustrated in
the figure over here.

So here we have the case that
everything was fine at the start

but then when the sender sends
two more segments here

the first of those segments is actually
lost because it's dropped

somewhere in the network and it
never arrives at the receiver.

So then what the receiver will do
is despite having received

that later segment here covering
the bytes between 4501 and 6000.

Since TCP does not acknowledge bytes
after loss

it will send back another acknowledgement
with the number 3001

because that is the number up to
at which point we've received

you know, a continuous stream of segments
and then we've lost a segment

and we received another segment
after that

but we do not acknowledge any
segments received after loss.

We'll sort of acknowledge whatever we
have received before the loss.

Actually there is a mechanism to
acknowledge segments

received after a loss.

It's called selective acknowledgements
but it's out of the scope of the unit.

So this is a bit more complicated than

the simple sort of
acknowledgement we discuss here

and it's implemented to
be much more efficient

since of course what
happens in this case here.

Once the receiver acknowledges
or it sends acknowledgement number 3001.

Of course what happens is the sender
will resend this segment here

starting with byte 3001 as well as
the next segment starting with byte 4001.

So despite the fact that
this segment the second here

was already received with cumulative
acknowledgements

we'll have to resend

or the sender has to resend
this again as well.

And so with selective ACs
we can do this way more efficiently

but it's also
way more complicated.

So it's out of scope of
the discussion here.

Next I want to talk about
another feature of TCP

which is called congestion control
TTP uses congestion control

to manage the rate
of transmission.

So you can think about it as
an accelerator and brake

on the rate of the transmission
and the TCP congestion window

specifies the maximum
number of unacknowledged segments

that can be in-flight
from sender to receiver.

Why do we actually
have congestion control?

Well let's do a little sort
of thought experiment here.

What if TCP senders could only send
one packet at a time without AC

If the round trip delay
between the sender and receiver

was something like two hundred
milliseconds then you know it would mean

that TCP could only
send five packets per second.

That would be very very slow .
certainly we wouldn't congest

the network but the TCP performance
would be horribly slow.

So what if on the other hand TCPs
senders could sent

as fast as a LAN connection permits for
example of one gigabit per second.

Well the gateway to
the Internet is usually a bottleneck,

and the gateway to the Internet,

If you think about home networks
for example it's unlikely to be able

to send with one gigabits
per second into the Internet.

So then we get what is called
congestion on the gateway.

So packets are building up in
the queues and eventually we have

full queues and any further
packets arriving will be dropped.

And you also need to consider
that we share the resources

we share the network with
many many other users.

So it's just a little picture here
to illustrate the links

that carry traffic between
different continents,

and you can see there's quite
a number of links between

United States and Asia,
and United States with Europe.

But it's not that many links connecting
Australia to the rest of the world.

So these are usually fiber
links and you can imagine that

those links you know that carry
the traffic of,

of billions or tens
or hundreds of millions

of concurrent TCP connections.

So all of these TCP connections
share the links

and so the question is how does
a TCP sender

find that the perfect rate,
so that fair share of a 100%

utilized bottleneck link speed.

So finding that you know that
perfect weight where we sort of

fairly share that think with lots
and lots of other TCP connections.

At the same time we'll utilize all
the bandwidth or the capacity

that it has while at the same time we'll
try to avoid congestion in routers.

Well that is the job of the congestion
control algorithm inside TCP.

And there are many congestion
control algorithms.

And on this slide also want to briefly
illustrate the new redo algorithm.

It's one of the traditional
algorithms that was

the default algorithm for a long
time in most operating systems.

So that algorithm has two phases
and has a slow start phase

and there's a congestion avoidance phase
and a slow start is actually not that slow

despite the fact that
it's named slow start.

So what slow start as is
or what TCP does

Slow start is it starts with an initial.

Congestion window of two segments or
these days will actually use 10 segments,

as the initial congestion window.

And then the sender will increase
the congestion window by one segment

for every packet acknowledged
by the receiver.

So this will lead to a relatively
quick increase in throughput

up to the maximum possible fare share.

By the time when the sender
detects packet loss.

It halves the window and then
it goes into congestion avoidance

In the and avoidance
phase without loss,

the window is increased by one
segment for each round trip time.

Round trip time means the time
it takes for a packet to go from A to B

and a response to come
back from B to A.

So that's that's a road trip
that's a round trip time.

So for each round trip sender will
increase the window by one segment

when the sender transmits to fast
and congests the link again,

then it will mean that you know
a congestion at the router occurs,

queues also,
and there will be packet drops.

When the sender detects those
packet drops it has its window

So this quickly shrinking off the window
will quickly reduce

the throughput of the connection
but it will also quickly reduce

the congestion on the bottleneck.

That's the idea.

And then after that we'll
have that sort of slow increase

in one segment
each round trip time again.

Where the sort of sender starts basically
sending more and more

until we sort of hit the limit again.

And to a sort of to better illustrate that
it's easiest to see this in a graph.

This is an actual graph
of the congestion window

of a single TCP connection
going through a bottleneck

and you can
see at the start here,

slow start where we have a rapid increase
of the congestion window

and then we have the first packet loss
and congestion we know sort of drops,

halved, it's halved again
and then we go into congestion avoidanc

and you can see us saw tooth pattern

and congestion
avoidance will basically...

Will slowly increase
the congestion window over time,

but when it's one to time
and then at some stage

we'll hit congestion again
if there's packet loss,

will quickly
or the sender will quickly

reduce the window to half of its size

and then we'll start
the upward probing again

until we hit loss again
half a window and so on.

So with a single flow through
a bottleneck we get to see

a perfect saw tooth pattern
of course with multiple flows.

This will look much messier
so to come back to the point of congestion

of congestion again so make it
very clear what it means is

so congestion occurs when
the number of packets arriving

at a router is higher than number of ACs
that can be sent on the next link.

So if we have lots of different
devices here,

all send packets to the router
then sent to the Internet.

And this is the one link to the Internet,
let's say,

and the link speed here of this link
is less than the combined link speeds

for all these different devices then.

Well we have to buffer
packets on the router

if the packet rates are too high
or higher than this link, right?

And if those rates are persistently
higher then this link

will then of course eventually
will get filled with all of our buffers.

And then the router has no choice
but to drop packets.

And then of course with TCP congestion
control we have the fact that

the TCP under senders
here will take that bus

as indication for congestion.

The window will be halved
and all of those devices here

will send a lot less packets.

Which then means the queues,
they can be drained,

and we won't have any loss
sort of in there (INAUDIBLE)

but again the window size
will increase again.

All those devices there was some sense of
faster and faster rates

based on the upward probing
of the congestion control algorithm

until the queues become full again
and we'll have the next packet loss,

and then we'll send less again
and so on.

Now you might say okay
well if the problem is packet loss

if packets are full then why not make
the router buffers really really big.

So we can basically avoid any any
packet losses

so we can have a case where either the
combined sender rates

can be higher than that

then you communicate for
a very very long time.

If we have big buffers
you can have it sort of

for varying something
like packet drops.

And this is what quite a number of people
actually used to think for years

and it led to a fairly large buffers
which caused another problem though

which is referred to as buffered load.

If buffer sizes are very large
then that means also the latency

will be quite high because
packets are stuck in those buffers

for quite some time.

And so remember your email will always
eventually fill the buffers

to full capacity and those large
buffers will take a long time to clear.

Any applications that require
reliability but also really benefit

from low latency that
say stock trading for example.

They have an issue with the high latency

that's caused by this buffered load

so buffers have to be reasonably small to
maintain a reasonably low network latency.

So we can't just make buffers really
really big that will cause problems

for applications that you know rely
on or benefit from lower latency.

So we talked about (INAUDIBLE)
which has been

the standard congestion control
mechanism for some time.

It's still used by Windows.

It was still used by Mac OS
until fairly recently.

But actually dozens
perhaps hundreds

including sort of research
research kind of algorithms

that exist,
Linux and Mac OS

now use a different algorithm
called cubic.

And there's also an algorithm called BBR,
it's been designed by Google

in recent years,
it has created a bit of a hype

Not all aim for maximum performance.

So some might have slightly different
aims and there's also algorithms

that use estimates of network delay
as an indicator of congestion as well

not just losses indicate of congestion

but also estimates of network
like for example BBR.

And despite the fact that
TCP is a fairly old protocol

TCP congestion control is
still a highly active

research area in data
communications.

There's also something called
active queue management.

So the idea is to improve things by
actually routers actively telling

TTP senders that there is congestion
sort of if routers could tell senders

and sort of some configure buffer
that is when there's congestion then,

senders could back off earlier and we
could avoid the packet loss.

So there are some algorithm
of active queue management

and there is something called TCP
early congestion notification.

And the idea is that the route of
the mock packets when the queue length

or the estimate layers
above computable threshold.

And then the TTP receiver
will echo those marks

back to the sender
and the sender can reduce

the congestion window before
we actually get to that stage

where we have packet loss.

So using this mechanism will
actually improve performance.

But it requires that routers
support this mechanism.

And of course senders and receivers
must also support the mechanism

Active queue management can actually
improve performance quite a bit

but many people don't actually notice.

So to illustrate that point,
I created this little slide here.

So we have the normal
sort of FIFO queues

and also two graphs
appear for FIFO queues

first in first out and then down here,

those two graphs are for
an active queue management mechanism.

called F Queue codal.

This is from an experiment
where we have...

when we look at the UpLink let's say

the uplink from your home network
to the Internet

and there's three traffic flows.

There is a gaming flow based
on UDP going upstream.

That's the dark blue line here so those
two graphs are throughput graphs,

so just write the throughput
of the three different traffic flows

so that flow here is a game traffic
it's veryy constant sort of throughput

and the other two traffic flows
are TCP connections.

So the light brown here, that's the
throughput of the TCP connections.

And those two graphs in
the right hand side here

show the RTT that those traffic
flows experience.

And the sort of fixed
delay for this experiment

was set to 100 milliseconds
of RTT and anything above

100 milliseconds is added,
constitutes delay added by

queueing the packets inside
the router and so you can see

with our traditional sort of
first in first out strategy

we'll get fairly high delays
and like all

the three different traffic
flows experienced

the same types of delays
and the like it's fairly high,

so we almost reached
300 milliseconds here

much much higher than
the sort of the base delay.

So when we do the same type
of experiments but with F Queue codal

to manage the queue then A you see
in the throughput graph here,

we got a bit of more fairness
in the sharing here I suppose

of the TCP flows closer to
the fair share

whereas here, that's a fair bit
of going up and down.

And the other thing you can see while
one thing is quite hard to see

but for the actual game traffic
here the delay is really minimal.

So the dark blue dots they
only extend up to here.

OK so we'll barely reach
125 milliseconds for the game traffic

which is of course very important
if you play first person shooter games

and for the TCP flows we get a little bit
more delay here but basically after that

so slow start fair, well,
we'll never really exceed

200 milliseconds of delay so you
can see the positive effect here

will reduce delay and we'll get
a fairer sharing here

and that's actually home routers where
you can you can turn this on

so you can actually change from FIFO
to F Queue codal.

so this is usually this
usually behind some

of the quality of of
service settings that

you can do with your routers here.

You can investigate and see
if your router supports it

and you might actually get
better quality of service

by turning those mechanisms on.

Another mechanism that TCP
has is CCP flow control

it's very similar to
congestion control but it's

to prevent the sender from
overflowing the receiver

instead of offering that
at the network bottleneck.

So I think at the sender receiver
having vastly different performance

for example a Netflix cache with
a low cost smart TV.

The way it works is the receiver
advertise the receive window

the number of bytes it will accept
before the next acknowledgement

or window update.

And then this is based on
the windowing mechanism

much like congestion control

and overall the sender will be
restricted to the minimum

of the congestion window and
the receive window of course

So that's why we're
basically trying to avoid

the network bottleneck and the receiver.

Alright and that's the basic
data about the TCP protocol.

Also the next couple of slides
will discuss the other

major transport protocol
the UDP datagrams protocol and...

Well as you will see here
UDP is much simpler.

So UDP is used when the data
must arrive in a timely manner

unlike TCP,
UDP is connectionless protocol.

So there's no connection set up,
connection tear down,

There's no notion of a
connection with UDP.

It's a best effort protocol and has
no equivalent to TCP acknowledgement.

So it's not necessarily
less reliable but there's

no reliability built in,
there's no reliability guaranteed.

If there is packet loss
then UDP datagrams

they're just lost and there's no
re transmitting mechanism.

Also if datagrams are reordered in
the network at the receiver

there's no attempt to reorder those
datagrams back into the original order.

It also has no congestion or flow control

but on the positive side with UDP
we very low pay packet overhead

so you have a much smaller
and simpler packet header.

The one thing that UDP has in common
with TCP, is port number.

So UDP has exactly the same sort of
port numbers

that TCP has, so same thing
and then you will see

it's got the same port number,
fields and header as I'll show you that

in aslide or two.

So yeah, to stress the point
about UDP right.

Reliability or lack thereof.

So UDP will not reassemble data packets
to the original order

and it will not resend lost datagrams
because it's connection is unreliable.

So this is sort of the same
that we looked at before

with TCP where datagrams
can take different

paths through the network
and with UDP if the order

is jumbled up because
of its different parts.

Well then the datagrams will be
delivered in this jumbled up order

to the application and then the
application has to sort that issue out.

So why would an application actually use

this kind of unreliable
transport protocol.

Well there's a couple of cases where

we prefer UDP over TCP.
And the first case is because

resending data is useless and we
want to avoid any additional delay.

So if you think about
teleconferencing

something like Skype or Discord
or whatever additional delay

for re transmissions are
more annoying than

the drop outs in the voice
similar online games.

There's no point in resending
packets after some actions

because you don't
really want a lag game.

So you'd rather take into account
that there maybe packet loss

and for example
use some redundancy.

That's what many games use,
so send data across multiple packets

so it doesn't matter if one is lost.

But we don't add any extra delay because

on games that might be
quite delay sensitive

if you think about first person
shooter games or similar games.

So that's one reason we want
to keep the delay sort of

really short and we don't need
to recent data.

Second case is we want to avoid
the complexities of TCP

and the omits of TCP.

So a full TCP implementation
is very complex and it may

be too complex for this human based
LCP or the RAM.

And the application can implement
a simple acknowledgement scheme

on top of UDP to transport
the item that's required.

An example of such a protocols,
it should be your file transfer protocols.

the FTP.

It's basically a simple sort of reliable
protocol that sits on top of UDP.

but it's simpler than
a full TCP implementation

And the third case where
you might want to use UDP

is because you want to avoid
the setup and the tear down.

of connections
that we have in TCP

because setting up
and tearing down TCP connections

requires a minimum of six packets.

OK that's a fair bit of sort of bandwidth,
it might be unnecessary

and also setting up connections requires
the server to be in state of connections

so that uses view CPU and also RAM
and you want to avoid that

If we have frequent so short
message exchanges

it's actually more efficient
and cheaper in terms of bandwidth.

So resources to use UDP and a prime
example of this is DNS lookups.

So with DNS we have serverss that
have to deal

with thousands of requests per second.

And the DNS requests plus
replies usually only two packets

so one packet for the request
and then there's one packet for the reply

and that's a quarter of the packets
that we would need with TCP

So remember we'll not only have
those two packets but an additional

six packets for setting up a
connection and then tearing it down.

Plus if we have those short message
exchanges then flow congestion

so flow control and congestion control

they're really useless
for these short flows

I mean that that they don't work.

They only work for so longer term flows.

And well last but not least if you
use UDP we can actually implement

a reliable transport protocol on top
of UDP without having to change

the operating system kernel because
remember the protocols stack up to

the transport layer actually implemented
in the operating system kernel.

And it's harder to make changes
there and it's impossible

if the operating system is closed source
so for example like Mac OS and windows.

So there is a protocol called Quick.
It's a new transport protocol,

it'ss developed
at Google to optimise

HTTP performance and to
you most likely use it

every day if you actually
use the Chrome browser.

And so the problem for Google
was they wanted to do

an improved protocol to improve
performance but pushing Quick

into the operating system
kernels of all sorts of

clients that would be very
difficult for Google to do.

But they own the Chrome browser
so they can very easily

implement a transport protocol on
top of UDP inside the browser.

So that's why they chose that avenue
of course in terms of resources

the implementation inside
the browser might

take up a few more cycles
in terms of CPU.

But the good thing for Google
is they fully control that

environment that can push
updates at any point in time

and they just have to update
chrome rather than having to

update lots and lots of different
operating systems.

Almost at the end so just have a quick
look at the UDP and TCP protocol

headers here so you can
see that the TTP protocol header

is much bigger
obviously because we have much

more functionality in TCP
and the UDP head down here.

You can see that both headers
have the source port

and the destination port as
the first two header fields and then

the UDP hasn't got much else besides
the length and the checksum

but TCP of course
we have the sequence numbers.

We have the acknowledgement numbers
we have the window size

and a bunch of flex to deal
with all the threeway handshake

tear downs and so on.

So let's discuss TCP by this UDP.

Well neither protocol is better.

It's just what's appropriate
for the application.

So if you're an application developer
you must decide what to use.

If your application, you know,
requires fast protocol, low overheads,

you don't need acknowledgments
you don't need to reset lost data

and you want to deliver data
as fast as it arrives

for example for things like IP tuner

for streaming rather
than UDP is your choice.

If you need reliability you'd
acknowledgements reending of those data

and data needs to be
delivered to the application.

in the order it was sent
which is the case for example

for applications
like email or web.

Then you should use TCP of course.
A little a homework for you

the following Cisco or network activity
let me just quickly switch to that.

So it's basically activity
to select

the right transport protocol
for a number of different applications.

So over here have all
those applications HDP

telnet FTP and we all discussed
a couple of those in the first lecture

and you basically
have to drag those boxes over here

to indicate where the something
is either TCP or UDP or both.

So one example HDP.

We discussed that uses TCP, right.

And you can check your answers.
That's correct.

Well I'll leave the rest
for you to do at home.

And I will conclude lecture as
much of lecture objectives

and you should be able to describe
a number of things

I won't go through all these
lecture objectives in detail

so just read all of those
and make sure you understand

all those concepts and you
can describe those concepts then...

Well today's lecture we looked at
the application presentation,

such layers and the two major
architect socommunications.

And we also looked at the transport layer

and the two main transport layer
protocols, TCP and UDP.

The readings for this week
introduction to the chapters 9 and 10.

And don't forget participation quiz.

One is to this Sunday and in the lapse
in the second week

we'll examining some network traffic
using a tool called Bioshock

so we look at actual DNS
packets and it's a three way handshake

and how those things
actually look on the web.

Oh well we'll look at those
things flash up.

And then the next week we will continue
descending down the old same model.

And so we'll talk about the network
LAN next week.

Specifically you'll look at IP addressing
and something called subnetting

And we will start discussing the role
of routers in data communications.

Well this is an online lecture
so you don't really sort of

bring pen and paper because
I assume you probably

have a pen and paper wherever
you're watching this lecture

but you have some pen
and paper ready for exercise.

That's it for me for this week.

I'll see you next week's lecture.