lecture_7_transport

lecture_7_transport - CS
536
Data
Communica0ons


Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: CS
536
Data
Communica0ons
 and
Computer
Networks
 Lecture
7:
Transport
 9/23/2008
 CS
536
Computer
Networks
 1
 Transport
Layer
 Our
goals:

 •  understand
principles
 behind
transport
layer
 services:
 –  mul0plexing/ demul0plexing
 –  reliable
data
transfer
 –  flow
control
 –  conges0on
control
 •  learn
about
transport
layer
 protocols
in
the
Internet:
 –  UDP:
connec0onless
transport
 –  TCP:
connec0on‐oriented
 transport
 –  TCP
conges0on
control
 CS
536
Computer
Networks 3‐2
 Outline
 •  3.1
Transport‐layer
services
 •  3.5
Connec0on‐oriented
 transport:
TCP
 •  3.2
Mul0plexing
and
 –  segment
structure
 demul0plexing
 –  reliable
data
transfer
 •  3.3
Connec0onless
 –  flow
control
 transport:
UDP
 –  connec0on
management
 •  3.4
Principles
of
reliable
 •  3.6
Principles
of
conges0on
 data
transfer
 control
 •  3.7
TCP
conges0on
control
 CS
536
Computer
Networks 3‐3
 Transport
services
and
protocols
 •  provide
logical
communica+on
 between
app
processes
running
 on
different
hosts
 •  transport
protocols
run
in
end
 systems

 –  send
side:
breaks
app
 messages
into
segments,
 passes
to

network
layer
 –  rcv
side:
reassembles
 segments
into
messages,
 passes
to
app
layer
 •  more
than
one
transport
protocol
 available
to
apps
 –  Internet:
TCP
and
UDP
 CS
536
Computer
Networks applica0on
 transport
 network
 data
link
 physical applica0on
 transport
 network
 data
link
 physical 3‐4
 Transport
vs.
network
layer
 •  network
layer:
logical
communica0on
between
hosts
 •  transport
layer:
logical
communica0on
between
 processes

 –  relies
on,
enhances,
network
layer
services
 CS
536
Computer
Networks 3‐5
 Internet
transport‐layer
protocols
 •  reliable,
in‐order
delivery
 (TCP)
 –  conges0on
control

 –  flow
control
 –  connec0on
setup
 applica0on
 transport
 network
 data
link
 physical network
 data
link
 physical network
 data
link
 physical •  unreliable,
unordered
 delivery:
UDP
 –  no‐frills
extension
of
“best‐ effort”
IP
 network
 data
link
 physical network
 data
link
 physical applica0on
 transport
 network
 data
link
 physical network
 data
link
 physical •  services
not
available:

 –  delay
guarantees
 –  bandwidth
guarantees
 CS
536
Computer
Networks network
 data
link
 physical 3‐6
 Outline
 •  3.1
Transport‐layer
services
 •  3.5
Connec0on‐oriented
 transport:
TCP
 •  3.2
Mul0plexing
and
 –  segment
structure
 demul0plexing
 –  reliable
data
transfer
 •  3.3
Connec0onless
 –  flow
control
 transport:
UDP
 –  connec0on
management
 •  3.4
Principles
of
reliable
 •  3.6
Principles
of
conges0on
 data
transfer
 control
 •  3.7
TCP
conges0on
control
 CS
536
Computer
Networks 3‐7
 Mul0plexing/demul0plexing
 Demul0plexing
at
rcv
host:
 delivering
received
segments
 to
correct
socket
 =
socket
 applica0on
 transport
 network
 link
 physical
 P3
 =
process
 P1
 P1
 applica0on
 transport
 network
 link
 physical
 P2
 P4
 applica0on
 transport
 network
 link
 physical
 Mul0plexing
at
send
host:
 gathering
data
from
mul0ple
 sockets,
enveloping
data
with

 header
(later
used
for

 demul0plexing) host
1
 host
2
 CS
536
Computer
Networks host
3
 3‐8
 How
demul0plexing
works
 •  host
receives
IP
datagrams
 –  each
datagram
has
source
IP
 address,
des0na0on
IP
address
 –  each
datagram
carries
1
 transport‐layer
segment
 –  each
segment
has
source,
 des0na0on
port
number

 •  host
uses
IP
addresses
&
port
 numbers
to
direct
segment
to
 appropriate
socket
 32
bits source
port
# dest
port
# other
header
fields applica0on
 data

 (message) TCP/UDP
segment
format CS
536
Computer
Networks 3‐9
 Connec0onless
demul0plexing
 •  Create
sockets
with
port
 numbers:
 DatagramSocket mySocket1 = new DatagramSocket(12534); DatagramSocket mySocket2 = new DatagramSocket(12535); •  When
host
receives
UDP
 segment:
 –  checks
des0na0on
port
 number
in
segment
 –  directs
UDP
segment
to
socket
 with
that
port
number
 •  UDP
socket
iden0fied
by

two‐ tuple:
 (dest
IP
address,
dest
port
number)
 •  IP
datagrams
with
different
 source
IP
addresses
and/or
 source
port
numbers
 directed
to
same
socket
 CS
536
Computer
Networks 3‐10
 Connec0onless
demux
(cont)
 DatagramSocket serverSocket = new DatagramSocket(6428); P2
 P3
 P1
 P1
 SP:
6428
 DP:
9157
 SP:
9157
 DP:
6428
 SP:
6428
 DP:
5775
 SP:
5775
 DP:
6428
 client
 
IP:
A
 server
 IP:
C
 Client
 IP:B
 SP
provides
“return
address”
 CS
536
Computer
Networks 3‐11
 Connec0on‐oriented
demux
 •  TCP
socket
iden0fied
by
4‐ tuple:

 –  –  –  –  source
IP
address
 source
port
number
 dest
IP
address
 dest
port
number
 •  Server
host
may
support
 many
simultaneous
TCP
 sockets:
 –  each
socket
iden0fied
by
its
 own
4‐tuple
 •  recv
host
uses
all
four
 values
to
direct
segment
to
 appropriate
socket
 •  Web
servers
have
different
 sockets
for
each
connec0ng
 client
 –  non‐persistent
HTTP
will
have
 different
socket
for
each
 request
 CS
536
Computer
Networks 3‐12
 Connec0on‐oriented
demux
(cont)
 P1
 P4
 P5
 P6
 SP:
5775
 DP:
80
 S‐IP:
B
 D‐IP:C
 SP:
9157
 DP:
80
 S‐IP:
A
 D‐IP:C
 SP:
9157
 DP:
80
 S‐IP:
B
 D‐IP:C
 P2
 P1
 P3
 client
 
IP:
A
 server
 IP:
C
 Client
 IP:B
 CS
536
Computer
Networks 3‐13
 Connec0on‐oriented
demux:
Threaded
 Web
Server
 P1
 P4
 SP:
5775
 DP:
80
 S‐IP:
B
 D‐IP:C
 SP:
9157
 DP:
80
 S‐IP:
A
 D‐IP:C
 SP:
9157
 DP:
80
 S‐IP:
B
 D‐IP:C
 P2
 P1
 P3
 client
 
IP:
A
 server
 IP:
C
 Client
 IP:B
 CS
536
Computer
Networks 3‐14
 Outline
 •  3.1
Transport‐layer
services
 •  3.5
Connec0on‐oriented
 transport:
TCP
 •  3.2
Mul0plexing
and
 –  segment
structure
 demul0plexing
 –  reliable
data
transfer
 •  3.3
Connec0onless
 –  flow
control
 transport:
UDP
 –  connec0on
management
 •  3.4
Principles
of
reliable
 •  3.6
Principles
of
conges0on
 data
transfer
 control
 •  3.7
TCP
conges0on
control
 CS
536
Computer
Networks 3‐15
 UDP:
User
Datagram
Protocol
[RFC
768]
 •  “no
frills,”
“bare
bones”
 Internet
transport
protocol
 •  “best
effort”
service,
UDP
 segments
may
be:
 –  lost
 –  delivered
out
of
order
to
 app
 •  connec+onless:
 –  no
handshaking
between
 UDP
sender,
receiver
 –  each
UDP
segment
handled
 independently
of
others
 Why
is
there
a
UDP?
 •  no
connec0on
establishment
 (which
can
add
delay)
 •  simple:
no
connec0on
state
at
 sender,
receiver
 •  small
segment
header
 •  no
conges0on
control:
UDP
can
 blast
away
as
fast
as
desired
 CS
536
Computer
Networks 3‐16
 UDP:
more
 •  ohen
used
for
streaming
 mul0media
apps
 –  loss
tolerant
 –  rate
sensi0ve
 32
bits Length,
in
 bytes
of
UDP
 segment,
 including
 header source
port
# length dest
port
# checksum •  other
UDP
uses
 –  DNS
 –  SNMP
 •  reliable
transfer
over
UDP:
add
 reliability
at
applica0on
layer
 –  applica0on‐specific
error
 recovery!
 Applica0on
 data

 (message) UDP
segment
format CS
536
Computer
Networks 3‐17
 UDP
checksum
 Goal:
detect
“errors”
(e.g.,
flipped
bits)
in
transmioed
 segment
 Sender:
 •  treat
segment
contents
as
 sequence
of
16‐bit
integers
 •  checksum:
addi0on
(1’s
 complement
sum)
of
segment
 contents
 •  sender
puts
checksum
value
 into
UDP
checksum
field
 Receiver:
 •  compute
checksum
of
received
 segment
 •  check
if
computed
checksum
 equals
checksum
field
value:
 –  NO
‐
error
detected
 –  YES
‐
no
error
detected.
But
 maybe
errors
nonetheless?
 More
later
….
 CS
536
Computer
Networks 3‐18
 Internet
Checksum
Example
 •  Note
 –  When
adding
numbers,
a
carryout
from
the
 most
significant
bit
needs
to
be
added
to
the
 result
 •  Example:
add
two
16‐bit
integers
 1

1

1

1

0

0

1

1

0

0

1

1

0

0

1

1

0
 1

1

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1
 wraparound
 1

1

0

1

1

1

0

1

1

1

0

1

1

1

0

1

1
 sum
 1

1

0

1

1

1

0

1

1

1

0

1

1

1

1

0

0
 checksum
 1

0

1

0

0

0

1

0

0

0

1

0

0

0

0

1

1
 CS
536
Computer
Networks 3‐19
 Outline
 •  3.1
Transport‐layer
services
 •  3.5
Connec0on‐oriented
 transport:
TCP
 •  3.2
Mul0plexing
and
 –  segment
structure
 demul0plexing
 –  reliable
data
transfer
 •  3.3
Connec0onless
 –  flow
control
 transport:
UDP
 –  connec0on
management
 •  3.4
Principles
of
reliable
 •  3.6
Principles
of
conges0on
 data
transfer
 control
 •  3.7
TCP
conges0on
control
 CS
536
Computer
Networks 3‐20
 Principles
of
Reliable
data
transfer
 •  important
in
app.,
transport,
link
layers
 •  top‐10
list
of
important
networking
topics!
 •  characteris0cs
of
unreliable
channel
will
determine
complexity
of
reliable
data
transfer
protocol
(rdt)
 CS
536
Computer
Networks 3‐21
 Principles
of
Reliable
data
transfer
 •  important
in
app.,
transport,
link
layers
 •  top‐10
list
of
important
networking
topics!
 •  characteris0cs
of
unreliable
channel
will
determine
complexity
of
reliable
data
transfer
protocol
(rdt)
 CS
536
Computer
Networks 3‐22
 Principles
of
Reliable
data
transfer
 •  important
in
app.,
transport,
link
layers
 •  top‐10
list
of
important
networking
topics!
 •  characteris0cs
of
unreliable
channel
will
determine
complexity
of
reliable
data
transfer
protocol
(rdt)
 CS
536
Computer
Networks 3‐23
 Reliable
data
transfer:
gepng
started
 rdt_send(): called
from
above,
 (e.g.,
by
app.).
Passed
data
to

 deliver
to
receiver
upper
layer deliver_data(): called
by
 rdt
to
deliver
data
to
upper send
 side receive
 side udt_send(): called
by
rdt,
 to
transfer
packet
over

 unreliable
channel
to
receiver rdt_rcv(): called
when
packet
 arrives
on
rcv‐side
of
channel CS
536
Computer
Networks 3‐24
 Reliable
data
transfer:
gepng
started
 We’ll:
 •  incrementally
develop
sender,
receiver
sides
of
 reliable
data
transfer
protocol
(rdt)
 •  consider
only
unidirec0onal
data
transfer
 –  but
control
info
will
flow
on
both
direc0ons!
 •  use
finite
state
machines
(FSM)

to
specify
sender,
 receiver
 event
causing
state
transi0on ac0ons
taken
on
state
transi0on event ac0ons state:
when
in
this
“state”
 next
state
uniquely
 determined
by
next
 event
 state
 1
 state
 2
 CS
536
Computer
Networks CS
536
Computer
Networks 3‐25
 3‐25
 Rdt1.0:
reliable
transfer
over
a
reliable
channel
 •  underlying
channel
perfectly
reliable
 –  no
bit
errors
 –  no
loss
of
packets
 •  separate
FSMs
for
sender,
receiver:
 –  sender
sends
data
into
underlying
channel
 –  receiver
read
data
from
underlying
channel
 Wait for call from above rdt_send(data) packet = make_pkt(data) udt_send(packet) Wait for call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) sender
 receiver
 CS
536
Computer
Networks 3‐26
 Rdt2.0:
channel
with
bit
errors
 •  underlying
channel
may
flip
bits
in
packet
 –  checksum
to
detect
bit
errors
 •  the
ques0on:
how
to
recover
from
errors:
 –  acknowledgements
(ACKs):
receiver
explicitly
tells
sender
that
pkt
 received
OK
 –  nega+ve
acknowledgements
(NAKs):
receiver
explicitly
tells
sender
 that
pkt
had
errors
 –  sender
retransmits
pkt
on
receipt
of
NAK
 –  Protocols
that
use
ACKS/NAKs
are
called
Automa0c
Repeate
 ReQuest
(ARQ)
protocols

 •  new
mechanisms
in
rdt2.0
(beyond
rdt1.0):
 –  error
detec0on
 –  receiver
feedback:
control
msgs
(ACK,NAK)
rcvr‐>sender
 –  Retransmission
 CS
536
Computer
Networks 3‐27
 rdt2.0:
FSM
specifica0on
 rdt_send(data) sndpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from above ACK or NAK udt_send(sndp kt) receiver
 rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 3‐28
 rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ sender
 This
is
an
example
of
a

 Stop‐and‐Wait
protocol
 CS
536
Computer
Networks rdt2.0:
opera0on
with
no
errors
 rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from above ACK or NAK udt_send(sndp kt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ CS
536
Computer
Networks 3‐29
 rdt2.0:
error
scenario
 rdt_send(data) snkpkt = make_pkt(data, checksum) rdt_rcv(rcvpkt) && udt_send(sndpkt) isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndp above NAK kt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) CS
536
Computer
Networks 3‐30
 rdt2.0
has
a
fatal
flaw!
 What
happens
if
ACK/NAK
 corrupted?
 •  sender
doesn’t
know
what
 happened
at
receiver!
 •  can’t
just
retransmit:
possible
 duplicate
 Handling
duplicates:

 •  sender
retransmits
current
pkt
 if
ACK/NAK
garbled
 •  sender
adds
sequence
number
 to
each
pkt
 •  receiver
discards
(doesn’t
 deliver
up)
duplicate
pkt
 stop
and
wait Sender
sends
one
packet,

 then
waits
for
receiver

 response CS
536
Computer
Networks 3‐31
 rdt2.1:
sender,
handles
garbled
ACK/NAKs
 rdt_send(data) sndpkt = make_pkt(0, data, checksum) rdt_rcv(rcvpkt) && udt_send(sndpkt) ( corrupt(rcvpkt) || Wait for Wait for isNAK(rcvpkt) ) ACK or call 0 from udt_send(sndpkt) NAK 0 above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Λ Wait for call 1 from above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Λ rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpk t) Wait for ACK or NAK 1 rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) CS
536
Computer
Networks 3‐32
 rdt2.1:
receiver,
handles
garbled
ACK/NAKs
 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Wait for 0 from below Wait for 1 from below rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) CS
536
Computer
Networks 3‐33
 rdt2.1:
discussion
 Sender:
 •  seq
#
added
to
pkt
 •  two
seq.
#’s
(0,1)
will
 suffice.

Why?
 •  must
check
if
received
ACK/ NAK
corrupted

 •  twice
as
many
states
 –  state
must
“remember”
 whether
“current”
pkt
has
0
 or
1
seq.
#
 Receiver:
 •  must
check
if
received
 packet
is
duplicate
 –  state
indicates
whether
0
or
1
 is
expected
pkt
seq
#
 •  note:
receiver
can
not
know
 if
its
last
ACK/NAK
received
 OK
at
sender
 CS
536
Computer
Networks 3‐34
 rdt2.2:
a
NAK‐free
protocol
 •  same
func0onality
as
rdt2.1,
using
ACKs
only
 •  instead
of
NAK,
receiver
sends
ACK
for
last
pkt
received
OK
 –  receiver
must
explicitly
include
seq
#
of
pkt
being
ACKed

 •  duplicate
ACK
at
sender
results
in
same
ac0on
as
NAK:
 retransmit
current
pkt
 CS
536
Computer
Networks 3‐35
 rdt2.2:
sender,
receiver
fragments
 rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) Wait for ACK 0 Wait for call 0 from above rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) Λ sender
FSM
 fragment
 rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt ) Wait for 0 from below receiver
FSM
 fragment
 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) CS
536
Computer
Networks udt_send(sndpkt) 3‐36
 rdt3.0:
channels
with
errors
and
loss
 New
assump0on:
underlying
 channel
can
also
lose
 packets
(data
or
ACKs)
 –  checksum,
seq.
#,
ACKs,
 retransmissions
will
be
of
 help,
but
not
enough
 Approach:
sender
waits “reasonable”
amount
of
 0me
for
ACK

 •  retransmits
if
no
ACK
received
in
 this
0me
 •  if
pkt
(or
ACK)
just
delayed
(not
 lost):
 –  retransmission
will
be

 duplicate,
but
use
of
seq.
#’s
 already
handles
this
 –  receiver
must
specify
seq
#
of
 pkt
being
ACKed
 •  requires
countdown
0mer
 3‐37
 CS
536
Computer
Networks ...
View Full Document

This note was uploaded on 10/24/2009 for the course CS 536 taught by Professor Sonia,f during the Spring '08 term at Purdue University.

Ask a homework question - tutors are online