Transcript 6: Transport Layer Overview

7: Transport Layer Overview
and UDP
Last Modified:
4/5/2017 6:08:35 PM
3: Transport Layer
3a-1
Transport Layer
Overview:
 transport layer services
 multiplexing/demultiplexing (socket to socket delivery)
 checksum
 Roadmap
 UDP: connectionless transport
 principles of reliable data transfer
 TCP: connection-oriented transport, flow control,
congestion control
3: Transport Layer
3a-2
Transport services and protocols
 provide logical communication




between processes running on
different hosts
transport protocols run in
end systems
transport vs network layer
services:
network layer: data transfer
between end systems
transport layer: data
transfer between processes

relies on, enhances, network
layer services
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
3: Transport Layer
3a-3
Transport protocol example
 A bit like volunteer at sorority or fraternity house
that collects all outgoing mail and delivers to post
office and takes incoming mail from post
 Analogy to the Internet





Hosts = House
Processes = people’s mailboxes
Application messages = letters in envelopes
Network layer protocol = postal service
Transport layer protocol = person who volunteers to
multiplex/demultiplex
• TCP? Make a copy of each outgoing letter, expect a return
receipt for each one and if not send a new copy, send return
receipts for each letter received
• If just hand out whatever comes in then like UDP
3: Transport Layer
3a-4
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
 connectionless:
 no handshaking between UDP sender, receiver
 each UDP segment handled independently of others

3: Transport Layer
3a-5
UDP Datagram Format
Length, in
bytes of UDP
datagram,
including
header
32 bits
source port #
dest port #
length
checksum
Application
data
 Entire UDP
header is 8
bytes
 Ports ( 16 bits
each) used for
multiplexing and
demultiplexing
 Length (16 bits)
used to find end
of data
 Checksum (16
bits) used to
detect errors
3: Transport Layer
3a-6
TCP segment structure
32 bits
Also 16 bits
for each
source and
destination
ports
Also
checksum
No length –
relies on
length in IP
header (UDP
could the
same)
source port #
dest port #
sequence number
acknowledgement number
head not
UA P R S F
len used
checksum
rcvr window size
ptr urgent data
Options (variable length)
application
data
(variable length)
3: Transport Layer
3b-7
Multiplexing/demultiplexing
Multiplexing:
gathering data from multiple
application processes on the
same host and sending out
the same network interface
32 bits
source port #
dest port #
other header fields
application
data
(message)
TCP/UDP segment format
Demultiplexing:
Stream of incoming data into
one machine separated into
smaller streams destined for
individual processes
Demultiplexing based on IP
addresses and port number
for both the sender and
receiver
 Can distinguish traffic
coming to same port but
part of separate
conversations (like
multiple client connections
to a web server)
3: Transport Layer
3a-8
Port Implementation
 Message queue
 Append incoming message to the end
 Much like a mailbox file
 Choose which message queue based on <src ip+ port, dest
ip +port>
 If queue full, ,message can be discarded
 why is that ok? Best effort delivery
 The network doesn’t guarantee not to drop, so the OS
needn’t guarantee that either
 When application, reads from socket, operating
system removes some bytes from the head of the
queue
 If queue empty, application blocks waiting
3: Transport Layer
3a-9
Connectionless demultiplexing
 recall: create sockets with
host-local port numbers:
DatagramSocket mySocket1 = new
DatagramSocket(12534);
DatagramSocket mySocket2 = new
DatagramSocket(12535);
 recall: when creating
datagram to send into UDP
socket, must specify
(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
Transport Layer
3-10
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
Transport Layer
3-11
Multiplexing/demultiplexing example
Two Web browsers on host A
each open 1 socket
Source IP: A
Dest IP: B
source port: x
dest. port: 80
<A,x> to<B,80>
Source IP: A
Dest IP: B
source port: t
dest. port: 80
<A,t> to<B,80>
Web
server B
One Web browser on
host C opens 2 sockets
Source IP: C
Dest IP: B
source port: x
dest. port: 80
<C,x> to<B,80>
Source IP: C
Dest IP: B
source port: y
dest. port: 80
<C,y> to<B,80>
3: Transport Layer 3a-12
Demultiplexing
 Packets arrive on
Process A
network
Process B
interface, copied
2 ports
1 port
up into system
User level
memory
 Placed in
Kernel level
message queue
by transport
protocol, dest IP
and port number,
src IP and port
number
Drop?
 Copied to user
level when app
Incoming messages
reads socket
3: Transport Layer 3a-13
Demultiplexing (cont)
 Receiving process may specify combinations
of <srcaddr, srcport, destaddr, destport>
it will receive or ANY
 Demultiplexing by port numbers and IP
address: other choices?
Ip address and process id? high overhead of
coordination and couldn’t have multiple streams
per process
 Additional level of addressing by port number
provides level of indirection and finer
granularity addressing

3: Transport Layer 3a-14
How many ports?
 Port field is 16
216
bits; so
or
64K possible
ports -not
enough for
whole
Internet, why
ok? Just for
the single
host!
 Plenty for
even NAT
32 bits
Length, in
bytes of UDP
datagram,
including
header
source port #
dest port #
length
checksum
Application
data
(message)
UDP datagram format
3: Transport Layer 3a-15
UDP header field: checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
Sender:
 treat segment contents
as sequence of 16-bit
integers (add 0 pad to get
even 16 bit chunks if
necessary)
 One's complement of the
sum of all the 16-bit
words in the segment.
 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 ….
 Errors could be anywhere –
in data, in headers, even in
checksum
3: Transport Layer 3a-16
Example
 Ones complement sum
of :



0110011001100110
0101010101010101
0000111100001111
 1’s complement of first
two (notice the carry)




0110011001100110
+ 0101010101010101
----------------1011101110111011
 Add in third

1011101110111011
 + 0000111100001111
 ----------------
1100101011001010
 Take 1’s complement
(ie flip all bits) to get
final checksum

0011010100110101
3: Transport Layer 3a-17
Pseudo-header
 Checksum over UDP header and the “pseudo
header” – not just the data
 12 byte Pseudo header precedes UDP header




Source and destination IP addresses from IP headers ( 4
bytes each)
Protocol ID from IP header ( 1 bytes)
Duplicated UDP length from UDP header ( 2 bytes) –
why?
1 byte of padding
 Pseudo header to double-check message correctly
delivered between endpoints.

Ex.Detect if IP address modified in transit
 Borrowing from the IP header is terribly un-
modular, but decided too expensive to do a
3: Transport Layer
checksum at both layers!
3a-18
UDP checksum optional?
 Actually optional
 If sender does not compute set checksum field to 0
 If calculated checksum is 0? Store it as all one bits
(65535) which is equivalent in ones-complement
arthimetic
 If checksum is non-zero and receiver computes a
different value, silently drop packet; no error msg
generated
 Shouldn’t do this unless end-to-end transfer on a
very reliable LAN like wired Ethernet
 Note: We will talk about more about error
detection and correction at the link layer….
3: Transport Layer 3a-19
UDP Header: length
 Length of data and header (min value 8
bytes = 0 bytes data)
 16 bit length field => max length of 65535
bytes
 Can you really send that much?
May be limited by kernel send buffer (often <=
8192 bytes)
 May be limited by kernel’s IP implementation
(possibly <= 512 bytes) ; Hosts required to
receive 576 bytes of UDP data so senders may
limit themselves to that as well

3: Transport Layer 3a-20
Why is there a UDP?
 Why wouldn’t everyone want reliable TCP?
 UDP has less overhead




UDP has no connection establishment (which can add delay)
UDP has small segment header
no congestion control: UDP can blast away as fast as desired
No connection state at sender, receiver
 If don’t need all TCP services



DNS: small, retransmit if necessary
reliable transfer over UDP: add reliability at application layer
application-specific error recover!
 Also TCP is based on a full duplex connection so can’t use to
send to multiple receivers at once (I.e. broadcast or
multicast)
 UDP often used for streaming multimedia apps for
multicast/broadcast and to avoid overhead
3: Transport Layer 3a-21
Experimenting with UDP
 Programs like sock, ttcp or pcattcp allow you to
generate streams of TCP or UDP data according to
your specifications (total amount of data to send,
size of each segment sent, etc.)
 Normally, procedure is as follows

Start tracer like Ethereal
• Consider a filter like (ip.addr eq senderIPaddress)


Start server process (ex. pcattcp –r –u)
Start client process sending traffic (ex. pcattcp –t –u <ip
address of server)
• Note: loopback or own IP address may not appear in
Ethereal

Experiment with different size sends –l bytes (default is
8192) or number of buffers to send –n sends (default is
2048)
Transport
• On Ethernet 1473 causes fragmentation, 14723:does
not Layer
3a-22
UDP Performance Experiments
 Vary buffer size , keep total data size the same
 Should see higher overall throughput when sending
in larger units Why? Many overheads are fixed



Packet headers
Kernel processing
Grabbing channel at physical layer
 Also interesting to repeat experiment across
different network conditions (on same hub, in
same AS, across ASes)


Throughout?
Data loss
3: Transport Layer 3a-23
TCP vs UDP on a LAN
 Compare overall throughput for TCP vs UDP
 Expect much lower throughput for TCP –
Why?
Connection establishment
 Slowstart
 Header overhead

 On a LAN, TCP shouldn’t see many
retransmissions
3: Transport Layer 3a-24
TCP vs UDP on a WAN
 Should see retransmissions and thus more
slow start/congestion avoidance overhead
 Quantify the effect
3: Transport Layer 3a-25
Roadmap
 UDP is a very thin layer over IP
 multiplexing /demultiplexing
 error detection
 TCP does these things also and then adds
some other significant features
 TCP is quite a bit more complicated and
subtle
 We are not going to jump right into TCP
 Start gently thinking about principles of
reliable message transfer in general
3: Transport Layer 3a-26