1

Ch. 7 : Internet Transport Protocols

Transport Layer

Transport LayerOur goals: understand

principles behind transport layer services: Multiplexing /

demultiplexing data streams of several applications

reliable data transfer flow control congestion control

Chapter 6: rdt principlesChapter 7: multiplex/ demultiplex Internet transport layer

protocols: UDP: connectionless

transport TCP: connection-oriented

transport• connection setup• data transfer• flow control• congestion control

22

Transport vs. network layer

Transport layer uses Network layer services adds more value to these services

Transport Layer Network Layer

logical communication between processes

logical communication between hosts

exists only in hostsexists in hosts and

in routers

ignores network routes data through network

Port #s used for routing in destination computer

IP addresses used for routing in network

3

4

Multiplexing &Demultiplexing

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

receive segment from L3deliver each received segment to correct socket

Demultiplexing at rcv host:gather data from multiplesockets, envelop data with headers (later used for demultiplexing), pass to L3

Multiplexing at send host:

5

How demultiplexing works host receives IP datagrams

each datagram has source IP address, destination IP address in its header

each datagram carries one transport-layer segment

each segment has source, destination port number in its header

host uses port numbers, and sometimes also IP addresses to direct segment to correct socket from socket data gets to

the relevant application process

source port # dest port #

32 bits

applicationdata

(message)

other header fields

TCP/UDP segment format

L4

head

er

ap

pl. m

sgL3

h

dr

other IP header fields

source IP addr dest IP addr.

6

Connectionless demultiplexing (UDP)

Processes create sockets with port numbers

a UDP socket is identified by a pair of numbers:(my IP address , my port number)

Client decides to contact: a server ( peer IP-address) + an application ( peer port #)

Client puts those into the UDP packet he sends; they are written as: dest IP address - in the

IP header of the packet dest port number - in its

UDP header

When server receives a UDP segment: checks destination port

number in segment directs UDP segment to

the socket with that port number (packets from different remote sockets directed to same socket)

the UDP message waits in socket queue and is processed in its turn.

answer message sent to the client UDP socket (listed in Source fields of query packet)

7

ClientIP:B

SP: 53

DP: 5775

S-IP: C

D-IP: B

SP = Source port numberDP= Destination port numberS-IP= Source IP AddressD-IP=Destination IP Address

Connectionless demux (cont)

client IP: A

P1

serverIP: C

SP and S-IP provide “return address”

P2

client socket:port=9157, IP=A

P3

server socket:port=53, IP = C

message

SP: 9157

DP: 53

S-IP: A

D-IP: C

IP-HeaderUDP-Header

SP: 53

DP: 9157

S-IP: C

D-IP: A

SP: 5775

DP: 53

S-IP: B

D-IP: C

message

client socket:port=5775, IP=B

message message

Wait for application

Getting Service

Reply

Getting Service

Reply

L1

L2

L4

L5

L3

8

Connection-oriented demux (TCP)

TCP socket identified by 4-tuple: local (my) IP address local (my) port number remote IP address remote port number

receiving 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 a different socket for each connecting client If you open two browser

windows, you generate 2 sockets at each end

non-persistent HTTP will open a different socket for each request

9

Connection-oriented demux (cont)

ClientIP: B

client IP: A

P1

serverIP: C

P3

client socket:LP= 9157, L-IP= ARP= 80 , R-IP= C

P1

LP= Local Port , RP= Remote Port L-IP= Local IP , R-IP= Remote IP

P4

server socket:LP= 80 , L-IP= CRP= 9157, R-IP= A

P6

server socket:LP= 80 , L-IP= CRP= 5775, R-IP= B

“L”= Local = My“R”= Remote = Peer

P2

client socket:LP= 5775, L-IP= BRP= 80 , R-IP= C

client socket:LP= 9157, L-IP= BRP= 80 , R-IP= C

P5

server socket:LP= 80 , L-IP= CRP= 9157, R-IP= B

H3

H4SP: 9157

DP: 80

S-IP: A

D-IP: C

packet:

message

SP: 5775

DP: 80

D-IP: CS-IP: B

packet:

message

SP: 9157

DP: 80

packet:

D-IP: CS-IP: B

message

L1

L2

L4

L5

L3

10

11

UDP Protocol

UDP: User Datagram Protocol [RFC 768]

simple transport protocol “best effort” service, UDP

segments may be: lost delivered out of order

to applicationwith no correction by UDP

UDP will discard bad checksum segments if so configured by application

connectionless: no handshaking

between UDP sender, receiver

each UDP segment handled independently of others

Why is there a UDP? no connection

establishment saves delay

no congestion control: better delay & BW

simple: small segment header typical usage: realtime

appl. loss tolerant rate sensitive

other uses (why?): DNS SNMP

12

UDP segment structure

source port # dest port #

32 bits

applicationdata (variable length)

length

Total length of segment (bytes)

Checksum computed over:• the whole segment• part of IP header:

– both IP addresses– protocol field – total IP packet length

checksum

Checksum usage:• computed at destination to detect

errors• in case of error, UDP will discard

the segment, or

13

14

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.

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

15

TCP Protocol

16

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

full duplex data: bi-directional data flow

in same connection MSS: maximum

segment size

connection-oriented: handshaking (exchange

of control msgs) init’s sender, receiver state before data exchange

flow controlled: sender will not

overwhelm receiver

point-to-point: one sender, one receiver between sockets

reliable, in-order byte steam: no “message

boundaries”

pipelined: TCP congestion and flow

control set window size

send & receive buffers

socketdoor

T C Psend buffer

T C Preceive buffer

socketdoor

segm ent

applicationwrites data

applicationreads data

17

TCP segment structure

source port # dest port #

32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberrcvr window size

ptr urgent datachecksum

FSRPAUheadlen

notused

Options (variable length)

URG: urgent data (generally not used)

ACK: ACK #valid

PSH: push data now(generally not used)

RST, SYN, FIN:connection estab(setup, teardown

commands)

# bytes rcvr willingto accept

countingby bytes of data(not segments!)

Internetchecksum

(as in UDP)

hdr length in 32 bit words

TCP sequence # (SN) and ACK (AN)SN:

byte stream “number” of first byte in segment’s data

AN: SN of next byte

expected from other side

cumulative ACKQn: how receiver handles

out-of-order segments? puts them in receive

buffer but does not acknowledge them

Host A Host B

time

SN=42, AN=79, 100 data bytes

SN=79, AN=142, 50 data bytes

SN=142, AN=129 , no data

host A sends100 data bytes

host ACKsreceipt of data , sends no dataWHY?

host B ACKs 100bytes and sends50 data bytes

simple data transfer scenario (some time after conn. setup)

18

19

Connection Management: Objective Agree on initial sequence numbers

a sender should not reuse a seq# before it is sure that all packets with the seq# are purged from the network

• the network guarantees that a packet too old will be purged from the network: network bounds the life time of each packet

To avoid waiting for seq #s to disappear, start new session with a seq# far away from previous

• needs connection setup so that the sender tells the receiver initial seq#

Agree on other initial parameters

TCP Connection ManagementSetup: establish connection

between the hosts before exchanging data segments

called: 3 way handshake initialize TCP variables:

seq. #s buffers, flow control

info (e.g. RcvWindow) client : connection initiator

opens socket and cmds OS to connect it to server

server : contacted by client has waiting socket accepts connection generates working socket

Teardown: end of connection(we skip the details)

Three way handshake:

Step 1: client host sends TCP SYN segment to server specifies initial seq # no data

Step 2: server host receives SYN, replies with SYNACK segment (also no data) allocates buffers specifies server initial

SN & window sizeStep 3: client receives

SYNACK, replies with ACK segment, which may contain data

20

TCP Three-Way Handshake (TWH)

A

Send Buffer

Receive Buffer

Send Buffer

Receive Buffer

SYN , SN = X

SYNACK , SN = Y, AN = X+1

ACK , SN = X+1 , AN = Y+1

X+1

X+1

Y+1

Y+1

B

21

22

Connection Close

Objective of closure handshake: each side can release

resource and remove state about the connection

• Close the socket

client

I am done. Are you done too?

server

I am done too. Goodbye!

initial close :

close

close

release resource?

release resource

release resource