cs 372 – introduction to computer networks* tuesday july 6
Post on 30-Dec-2015
29 Views
Preview:
DESCRIPTION
TRANSCRIPT
Chapter 3, slide: 1
CS 372 – introduction to computer networks*Tuesday July 6
Announcements: Lab 2 is due today
Acknowledgement: slides drawn heavily from Kurose & Ross
* Based in part on slides by Bechir Hamdaoui and Paul D. Paulson.
Chapter 3, slide: 2
application architectures client-server P2P
application service requirements: reliability, bandwidth, delay
Transport service model connection-oriented,
reliable: TCP unreliable, datagrams: UDP
By now, you should know:
Important concepts: centralized vs.
decentralized stateless vs. stateful reliable vs. unreliable
msg transfer
Chapter 2: Recap
Chapter 3, slide: 3
Chapter 3: Transport Layer
Our goals: understand
principles behind transport layer services: multiplexing/
demultiplexing reliable data
transfer flow control congestion control
learn about transport layer protocols in the Internet: UDP: connectionless
transport TCP: connection-
oriented transport TCP congestion
control
Chapter 3, slide: 4
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: 5
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
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
logical end-end transport
Chapter 3, slide: 6
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 = network-
layer protocol
Chapter 3, slide: 7
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
transportnetworkdata linkphysical network
data linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
application
transportnetworkdata linkphysical
logical end-end transport
Chapter 3, slide: 8
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: 9
Multiplexing/demultiplexing
application
transport
network
link
physical
P1 application
transport
network
link
physical
application
transport
network
link
physical
P2P3 P4P1
host 1 host 2 host 3
= process= socket
delivering received segmentsto correct socket
Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data with header (later used for demultiplexing)
Multiplexing at send host:
Chapter 3, slide: 10
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
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
Chapter 3, slide: 11
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: 12
Connectionless demux (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);
ClientIP:B
P2
client IP: A
P1P1P3
serverIP: C
SP: 6428
DP: 9157
SP: 9157
DP: 6428
SP: 6428
DP: 5775
SP: 5775
DP: 6428
SP provides “return address”
Chapter 3, slide: 13
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: 14
Connection-oriented demux (cont)
ClientIP:B
P1
client IP: A
P1P2P4
serverIP: C
SP: 9157
DP: 80
SP: 9157
DP: 80
P5 P6 P3
D-IP:CS-IP: A
D-IP:C
S-IP: B
SP: 5775
DP: 80
D-IP:CS-IP: B
Chapter 3, slide: 15
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: 16
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: 17
UDP: more
often used for streaming multimedia apps loss tolerant rate sensitive
other UDP uses DNS SNMP
reliable transfer over UDP: add reliability at application layer application-specific
error recovery!
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksumLength, in
bytes of UDPsegment,including
header
Chapter 3, slide:
UDP checksum
Sender: treat segment contents
as sequence of 16-bit integers
checksum: addition (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 ….
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
18
Chapter 3, slide:
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
19
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
wraparound
sumchecksum
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 Description7 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)
Chapter 3, slide: 22
Review questionsQuestion 1: Host C has UDP socket with port
number 6789 Both Hosts A & B send UDP
segment with destination Port 67891. Would both be directed to same
socket at Host C?2. If so, how would Host C know that
these 2 are originated from two different hosts?
Answer: 1. Yes2. 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: 23
CS 372 – introduction to computer networks*Wednesday July 7
Announcements: Quiz on Friday, covers chapter 2
Acknowledgement: slides drawn heavily from Kurose & Ross
* Based in part on slides by Bechir Hamdaoui and Paul D. Paulson.
Chapter 3, slide: 24
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: 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
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: 28
Reliable data transfer: getting started
sendside
receiveside
rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer
udt_send(): called by rdt,to transfer packet over unreliable channel to
receiver
rdt_rcv(): called when packet arrives on rcv-side of channel
deliver_data(): called by rdt to deliver data to
upper
Chapter 3, slide: 29
Reliable data transfer: getting startedWe 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
state1
state2
event causing state transitionactions taken on state transition
state: when in this “state” next state
uniquely determined by
next event
eventactions
Chapter 3, slide: 30
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 packet = make_pkt(data)
udt_send(packet)
rdt_send(data)
extract (packet,data)deliver_data(data)
Wait for call from
below
rdt_rcv(packet)
sender receiver
Chapter 3, slide: 31
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: 32
rdt2.0: FSM specification
Wait for call from above
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
Wait for ACK or
NAK
sender
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for call from
below
receiverrdt_send(data)
Note: means “transition to next state”
Chapter 3, slide: 33
rdt2.0: operation with no errors
Wait for call from above
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for ACK or
NAK
Wait for call from
below
rdt_send(data)
sender
receiver
Chapter 3, slide: 34
rdt2.0: error scenario
Wait for call from above
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for ACK or
NAK
Wait for call from
below
rdt_send(data)
top related