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 Layerlogical communication

between processes logical communication

between hostsexists only in hosts exists in hosts and

in routersignores 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

erap

pl. m

sgL3

hd

r

other IP header fieldssource 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: 53DP: 5775

S-IP: CD-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

P3server socket:port=53, IP = C

message

SP: 9157DP: 53

S-IP: AD-IP: C

IP-HeaderUDP-Header

SP: 53DP: 9157

S-IP: CD-IP: A

SP: 5775DP: 53

S-IP: BD-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: 9157DP: 80

S-IP: AD-IP: C

packet:

message

SP: 5775DP: 80

D-IP: CS-IP: B

packet:

message

SP: 9157DP: 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

TC Prece ive buffer

socketdoor

segm en t

applica tionwrites data

applicationreads data

17

TCP segment structure

source port # dest port #32 bits

applicationdata

(variable length)

sequence numberacknowledgement

numberrcvr window sizeptr 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