3: transport layer 3a-1 7: transport layer overview and udp last modified: 10/21/2015 9:17:26 pm

3: Transport Layer 3a-1

7: Transport Layer Overview and UDP

Last Modified: 04/20/23 02:36 AM


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


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

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysical

logical end-end transport


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


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


UDP Datagram Format

source port # dest port #

32 bits

Applicationdata

length checksum

Length, inbytes of UDP

datagram,including

header

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 3b-7

TCP segment structure


32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberrcvr window size

ptr urgent datachecksum

FSRPAUheadlen

notused

Options (variable length)

Also 16 bits for each

source and destination

ports

Also checksum

No length – relies on

length in IP header

(UDP could the same)


Multiplexing/demultiplexing

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)

gathering data from multiple application processes on the same host and sending outthe same network interface


32 bits

applicationdata

(message)

other header fields

TCP/UDP segment format

Multiplexing:

Stream of incoming data into one machine separated into smaller streams destined for individual processes

Demultiplexing:


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

Transport Layer 3-10

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-11

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


Multiplexing/demultiplexing example

Two Web browsers on host Aeach open 1 socket

Webserver B

One Web browser onhost C opens 2 sockets

Source IP: CDest IP: B

source port: y

dest. port: 80

Source IP: CDest IP: B

source port: x

dest. port: 80

Source IP: ADest IP: B

source port: x

dest. port: 80

<C,x> to<B,80><A,x> to<B,80> <C,y> to<B,80>

Source IP: ADest IP: B

source port: t

dest. port: 80

<A,t> to<B,80>


Demultiplexing Packets arrive

on network interface, copied up into system memory

Placed in message queue by transport protocol, dest IP and port number, src IP and port number

Copied to user level when app reads socket

Drop?

Process A2 ports

Process B1 port

User level

Kernel level

Incoming messages


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


How many ports?

Port field is 16 bits; so 216 or 64K possible ports -not enough for whole Internet, why ok? Just for the single host!

Plenty for even NAT


32 bits

Applicationdata

(message)

UDP datagram format

length checksumLength, in

bytes of UDPdatagram,

includingheader


UDP header field: checksum

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

Goal: detect “errors” (e.g., flipped bits) in transmitted segment


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


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 checksum at both layers!


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….


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


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


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)

• On Ethernet 1473 causes fragmentation, 1472 does not


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


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


TCP vs UDP on a WAN

Should see retransmissions and thus more slow start/congestion avoidance overhead

Quantify the effect


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-1 7: transport layer overview and udp last modified: 10/21/2015 9:17:26 pm

Documents

transport layer3a

transport services

transport layer3b

transport layeroverview

transport layer overview

transport protocol examplea

connectionoriented transport

udp sender