CS 372 Lecture #16 The Transport Layer:
• Reliable data transer
• Motivations, concerns, and principles • Error detection
ote: Many of the lecture slides are based on presentations that accompany Computer Networking: A Top Down Approach, 6th edition,
v
by Jim Kurose & Keith Ross, Addison-Wesley, 2013.
N
Or•egon State University
Two Generals Problem
oCannot guarantee that message will be received
oCannot guarantee that received message has no errors
oIs reliable messaging possible? oSee “Two Generals Problem”
on wikipedia
oSee also RFC1149
Positions of the armies. Armies A1 and A2 need to communicate but their messengers may be captured by army B.
Principles of reliable data transfer (rdt)
C
0 +-~
Q_
a
t:
0~ Q _ (1)
en >
a
(1) 0>
sen 1ng rocess
IdataI
receiver
=a Q_-
C0
o-
~
udt_send()t I
II
+-
packet! l rdt_rcv() 1..c)unreliable channe1)J
(b) service implementation
reliable channel
rdt- send ()-,, ~ reliable data
transfer protocol (sending side)
ldatardeliver data () reliable data
transfer protocol (receivinQ side)
(a) provided service
• Unreliable channel will determine complexity of rdt protocol • implemented in application, transport, network, link layers
packet
Reliable data transfer: getting started
rdt_send(): called from application layer. Data to be delivered to receive-side application layer
\ rdt_send() ldataI ldataItdeliver data()
send reliable data side transfer protocol
(sending side) udt_send ot Ipacket I
reliable data receive
transfer protocol (receivinq side)
side
Ipacket! trdt_rcv () YJunreliablechannel )J
deliver_data(): called by rdt to deliver data to application layer
rdt_rcv(): called from “below” when packet arrives on receive- side of channel
udt_send(): called by rdt, to transfer packet over unreliable channel to receiver
Reliable data transfer: how reliable?
o“reliable” is a relative term
oSmall steps:
oError detection
o Acknowledgement
o Sequencing
oTiming (flow/congestion control) o Retransmission
o Fairness
oSee textbook for development of reliable data transfer (using finite state diagrams)
Error detection in UDP [RFC 768]
oIn addition to port numbers, UDP segment header includes
o 16-bit length field
o 16-bit checksum field
32 bits
source port #
length
dest port #
checksum
Application data
(message)
length, in bytes of UDP segment, including header
one’s complement sum of segment contents
UDP segment format
UDP Checksum
Goal: detect errors (e.g., flipped/lost bits) in transmitted segment
sender:
ostart checksum = 0 ocompute checksum:
receiver:
• compute checksum of received segment
• compare computed checksum to segment checksum field.
• Equal – no error detected
• But may be errors anyway!!
• Not equal – error detected • Discard entire packet
o ones-complement of sum of segment contents as 16- bit integers
o see Short Description of the Internet Checksum
Discussion question: Why use the 1’s-complement, instead of just the sum?
Internet checksum: example
example: add two 16-bit integers
11110011001100110 11101010101010101
wraparound
sum checksum
Note: when adding numbers, a carryout from the most significant bit needs to be added to the result
11011101110111011 11011101110111100
10100010001000011
UDP: Summary o“no frills,” “bare bones”
transport protocol o“best effort” service obasic error detection
oUDP segments may be o lost
o delivered out-of-order o connectionless:
o no handshaking between UDP sender, receiver
o each UDP segment handled independently of others
• UDP use:
– streaming multimedia apps (loss tolerant, rate sensitive)
– DNS
why is there a UDP?
• no connection establishment (which can add delay)
• simple: no connection state at sender, receiver
• small header size
• no congestion control: UDP can blast away as fast as desired
Summary Lecture #16
oTwo generals problem oReliable data transfer oError detection oCharacteristics of UDP
Discussion topic: When UDP detects an error, the packet is discarded without warning to the sender. Discuss the advantages and disadvantages of implementing error-correction at the transport layer. (e.g., Hamming codes)