Transcript lectures1-2

CS 372 – introduction to computer networks*
Tuesday July 6
Announcements:
 Lab 2 is due today
* Based in part on slides by Bechir Hamdaoui and Paul D. Paulson.
Acknowledgement: slides drawn heavily from Kurose & Ross
Chapter 3, slide: 1
Chapter 2: Recap
By now, you should know:
 application architectures
 client-server
 P2P
 application service
requirements:

reliability, bandwidth, delay
 Transport service model
 connection-oriented, reliable:
TCP
 unreliable, datagrams: UDP
Important concepts:
 centralized vs.
decentralized
 stateless vs. stateful
 reliable vs. unreliable
msg transfer
Chapter 3, slide: 2
Chapter 3: Transport Layer
Our goals:
 understand
principles behind
transport layer
services:
multiplexing/demu
ltiplexing
 reliable data
transfer
 flow control
 congestion control

 learn about transport
layer protocols in the
Internet:
UDP: connectionless
transport
 TCP: connectionoriented transport
 TCP congestion control

Chapter 3, slide: 3
Chapter 3 outline
 1 Transport-layer
services
 2 Multiplexing and
demultiplexing
 3 Connectionless
transport: UDP
 4 Principles of reliable
data transfer
 5 Connection-oriented
transport: TCP




segment structure
reliable data transfer
flow control
connection management
 6 Principles of
congestion control
 7 TCP congestion control
Chapter 3, slide: 4
Transport services and protocols
 provide logical communication
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
application
transport
network
data link
physical
application
transport
network
data link
physical
Chapter 3, slide: 5
Transport vs. network layer
 network layer: logical communication between hosts
 transport layer: logical communication between processes
Household case:
 12 kids (East coast house)
sending letters to 12 kids
(West coast house)
 Ann is responsible for the
house at East coast
 Bill is responsible for the
house at West coast
 Postal service is
responsible for between
houses
Household analogy:
 kids = processes
 letters = messages
 houses = hosts
 home address = IP address
 kid names = port numbers
 Ann and Bill = transport
protocol
 postal service = networklayer protocol
Chapter 3, slide: 6
Internet transport-layer protocols
 reliable, in-order
delivery (TCP)



congestion control
flow control
connection setup
 unreliable, unordered
delivery: UDP

no-frills extension of
“best-effort” IP
 services not available:
 delay guarantees
 bandwidth guarantees
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physicalnetwork
network
data link
physical
data link
physical
network
data link
physical
application
transport
network
data link
physical
Chapter 3, slide: 7
Chapter 3 outline
 1 Transport-layer
services
 2 Multiplexing and
demultiplexing
 3 Connectionless
transport: UDP
 4 Principles of reliable
data transfer
 5 Connection-oriented
transport: TCP




segment structure
reliable data transfer
flow control
connection management
 6 Principles of
congestion control
 7 TCP congestion control
Chapter 3, slide: 8
Multiplexing/demultiplexing
Multiplexing at send host:
gathering data from multiple
sockets, enveloping data with
header (later used for
demultiplexing)
Demultiplexing at rcv host:
delivering received segments
to correct socket
= socket
application
transport
network
link
= process
P3
P1
P1
application
transport
network
P2
P4
application
transport
network
link
link
physical
host 1
physical
host 2
physical
host 3
Chapter 3, slide: 9
How demultiplexing works
 host receives IP datagrams
each datagram has source
IP address, destination IP
address
 each datagram carries 1
transport-layer segment
 each segment has source,
destination port number
 host uses IP addresses & port
numbers to direct segment to
appropriate socket

32 bits
source port #
dest port #
other header fields
application
data
(message)
TCP/UDP segment format
Chapter 3, slide: 10
Connectionless demultiplexing
 UDP socket identified by
two-tuple:
(dest IP address, dest port number)
 When host receives UDP
segment:


checks destination port
number in segment
directs UDP segment to
socket with that port number
 IP datagrams with
different source IP
addresses and/or source
port numbers directed
to same socket
 Demultiplexing in UDP is
based on destination
only!
Chapter 3, slide: 11
Connectionless demux (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);
P2
SP: 6428
SP: 6428
DP: 9157
DP: 5775
SP: 9157
client
IP: A
P1
P1
P3
DP: 6428
SP: 5775
server
IP: C
DP: 6428
Client
IP:B
SP provides “return address”
Chapter 3, slide: 12
Connection-oriented demux
 TCP socket identified
by 4-tuple:




source IP address
source port number
dest IP address
dest port number
 recv host uses all four
values to direct
segment to appropriate
socket
 Server host may support
many simultaneous TCP
sockets:

each socket identified by
its own 4-tuple
 Web servers have
different sockets for
each connecting client

non-persistent HTTP will
have different socket for
each request
Chapter 3, slide: 13
Connection-oriented demux
(cont)
P1
P4
P5
P2
P6
P1P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
SP: 9157
client
IP: A
DP: 80
S-IP: A
D-IP:C
SP: 9157
server
IP: C
DP: 80
S-IP: B
D-IP:C
Client
IP:B
Chapter 3, slide: 14
Chapter 3 outline
 1 Transport-layer
services
 2 Multiplexing and
demultiplexing
 3 Connectionless
transport: UDP
 4 Principles of reliable
data transfer
 5 Connection-oriented
transport: TCP




segment structure
reliable data transfer
flow control
connection management
 6 Principles of
congestion control
 7 TCP congestion control
Chapter 3, slide: 15
UDP: User Datagram Protocol [RFC 768]
 “best effort” service, UDP
segments may be:
 lost
 delivered out of order
to app
 connectionless:
 no handshaking between
UDP sender, receiver
 each UDP segment
handled independently
of others
Why is there a UDP?
 less delay: no connection
establishment (which can
add delay)
 simple: no connection state
at sender, receiver
 less traffic: small segment
header
 no congestion control: UDP
can blast away as fast as
desired
Chapter 3, slide: 16
UDP: more
 often used for streaming
multimedia apps
 loss tolerant
 rate sensitive
Length, in
bytes of UDP
segment,
including
header
 other UDP uses
 DNS
 SNMP
 reliable transfer over UDP:
add reliability at
application layer
 application-specific
error recovery!
32 bits
source port #
dest port #
length
checksum
Application
data
(message)
UDP segment format
Chapter 3, slide: 17
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
Sender:
Receiver:
 treat segment contents
 compute checksum of
as sequence of 16-bit
integers
 checksum: addition (1’s
complement sum) of
segment contents
 sender puts checksum
value into UDP checksum
field
received segment
 check if computed checksum
equals checksum field value:
 NO - error detected
 YES - no error detected.
But maybe errors
nonetheless? More later
….
Chapter 3, slide: 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
Chapter 3, slide: 19
Selecting logical port numbers
 Communicating computers must agree on a port
number


Server opens selected port and waits for incoming messages
Client selects local port and sends message to selected
server port
 Many common services use reserved (well-known) port
numbers
 Other services use dynamically assigned port numbers
 Valid range is [0 .. 65535] , but don’t use “well-known”
port numbers for special apps.
Some "well-known" logical port numbers
Port
Name
Description
7
echo
Echo input back to sender
11
systat
System statistics
13
daytime
Time of day (ASCII)
17
quote
Quote of the day
20,21
ftp
File Transfer Protocol
22
ssh
Secure Shell remote login
23
telnet
Telnet
37
time
System time (seconds since 1970)
53
domain
Domain Name Service (DNS)
80
web, http
World Wide Web (HTTP)
123
ntp
Network Time Protocol (NTP)
161
snmp
Simple Network Management Protocol (SNMP)
Review questions
Question 1:


1.
2.
Host C has UDP socket with port
number 6789
Both Hosts A & B send UDP segment
with destination Port 6789
Would both be directed to same
socket at Host C?
If so, how would Host C know that
these 2 are originated from two
different hosts?
Answer:
1.
2.
Yes
IP addresses
Question 2:

Same scenario
but with TCP
instead of UDP
Answer:

No!
There is a
separate TCP
socket for each
4-uplet (IP src,
IP dst, src Port,
dst Port)
Chapter 3, slide: 22
CS 372 – introduction to computer networks*
Wednesday July 7
Announcements:
 Quiz on Friday, covers chapter 2
* Based in part on slides by Bechir Hamdaoui and Paul D. Paulson.
Acknowledgement: slides drawn heavily from Kurose & Ross
Chapter 3, slide: 23
Chapter 3 outline
 1 Transport-layer
services
 2 Multiplexing and
demultiplexing
 3 Connectionless
transport: UDP
 4 Principles of reliable
data transfer
 5 Connection-oriented
transport: TCP




segment structure
reliable data transfer
flow control
connection management
 6 Principles of
congestion control
 7 TCP congestion control
Chapter 3, slide: 24
Principles of Reliable data transfer
 important in app., transport, link layers
 top-10 list of important networking topics!
 characteristics of unreliable channel will determine
complexity of reliable data transfer protocol (rdt)
Chapter 3, slide: 25
Principles of Reliable data transfer
 important in app., transport, link layers
 top-10 list of important networking topics!
 characteristics of unreliable channel will determine
complexity of reliable data transfer protocol (rdt)
Chapter 3, slide: 26
Principles of Reliable data transfer
 important in app., transport, link layers
 top-10 list of important networking topics!
 characteristics of unreliable channel will determine
complexity of reliable data transfer protocol (rdt)
Chapter 3, slide: 27
Reliable data transfer: getting started
rdt_send(): called from above,
(e.g., by app.). Passed data to
deliver to receiver upper layer
send
side
udt_send(): called by rdt,
to transfer packet over
unreliable channel to receiver
deliver_data(): called by
rdt to deliver data to upper
receive
side
rdt_rcv(): called when packet
arrives on rcv-side of channel
Chapter 3, slide: 28
Reliable data transfer: getting started
We will:
 incrementally develop sender, receiver sides of
reliable data transfer protocol (rdt)
 consider only unidirectional data transfer

but control info will flow on both directions!
 use finite state machines (FSM) to specify
sender, receiver
state: when in this
“state” next state
uniquely determined
by next event
state
1
event causing state transition
actions taken on state transition
event
actions
state
2
Chapter 3, slide: 29
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)
sender
Wait for
call from
below
rdt_rcv(packet)
extract (packet,data)
deliver_data(data)
receiver
Chapter 3, slide: 30
rdt2.0: channel with bit errors
 underlying channel may flip bits in packet
 Receiver can detect bit errors (e.g., use checksum)
 But still no packet loss
 questions: (1) how to know and (2) what to do when
packet is erroneous:

acknowledgements:
• positive ack (ACK): receiver tells sender that pkt received OK
• negative ack (NAK): receiver tells sender that pkt had erros

retransmission: sender retransmits pkt on receipt of NAK
 new mechanisms in rdt2.0 (beyond rdt1.0):



error detection
receiver feedback: control msgs (ACK,NAK) rcvr->sender
assume ACK/NAK are error free
Chapter 3, slide: 31
rdt2.0: FSM specification
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for
Wait for
call from
ACK or
udt_send(sndpkt)
above
NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
L
sender
Note: L means
“transition to next state”
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)
Chapter 3, slide: 32
rdt2.0: operation 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
ACK or
udt_send(sndpkt)
above
NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
L
sender
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)
Chapter 3, slide: 33
rdt2.0: error scenario
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for
Wait for
call from
ACK or
udt_send(sndpkt)
above
NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
L
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)
Chapter 3, slide: 34