transport layer abusayeed saifullah cs 5600 computer networks these slides are adapted from kurose...

Transport Layer

Abusayeed Saifullah

CS 5600 Computer Networks

These slides are adapted from Kurose and Ross

Transport Layerour goals: understand principles behind transport layer services: multiplexing, demultiplexing

reliable data transfer

flow control congestion control

learn about Internet transport layer protocols: UDP: connectionless transport

TCP: connection-oriented reliable transport

TCP congestion control

Roadmap

1 transport-layer services

2 multiplexing and demultiplexing

3 connectionless transport: UDP

4 connection-oriented transport: TCP segment structure reliable data transfer

flow control connection management

5 principles of congestion control

6 TCP congestion control

Transport services and protocols

provide logical communication between app processes running on different hosts

transport protocols run in end systems send side: breaks app messages into segments, passes to network layer

rcv side: reassembles segments into messages, passes to app layer

more than one transport protocol available to apps Internet: TCP and UDP

application

transport

networkdata link

physical

logical end-end transport

application

transport

networkdata link

physical

Transport vs. network layer network layer: logical communication between hosts

transport layer: logical communication between processes relies on, enhances, network layer services

12 kids in Ann’s house sending letters to 12 kids in Bill’s house: Ann and Bill collect and distribute mails for their respective houses

hosts = houses processes = kids app messages = letters in envelopes

transport protocol = Ann and Bill who demux to in-house siblings

network-layer protocol = postal service

household analogy:

Internet transport-layer protocols

reliable, in-order delivery (TCP) congestion control flow control connection setup

unreliable, unordered delivery: UDP no-frills extension of “best-effort” IP

services not available: delay guarantees bandwidth guarantees

application

transport

networkdata link

physical

application

transport

networkdata link

physical

networkdata link

physical networkdata link

physical

networkdata link

physical

networkdata link

physicalnetworkdata link

physicalnetworkdata link

physical networkdata link

physical

logical end-end transport

Roadmap








Multiplexing/demultiplexing

process

socket

use header info to deliverreceived segments to correct socket

demultiplexing at receiver:handle data from multiplesockets, add transport header (later used for demultiplexing)

multiplexing at sender:

transport

application

physical

link

network

P2P1

transport

application

physical

link

network

P4

transport

application

physical

link

network

P3

Multiplexing

Multiplexing requires thatSockets have unique identifiers Each transport layer segment has special fields that indicate the socket to which the segment is to be delivered

UDP socket is identified by2-tuple: destination IP, destination port

TCP socket is identified by4-tuple: dest IP, dest port, source IP, source port

How demultiplexing works

host receives IP datagrams each datagram has source IP address, destination IP address

each datagram carries one transport-layer segment

each segment has source, destination port number

host uses IP addresses & port numbers to direct segment to appropriate socket

source port #dest port #

32 bits

applicationdata

(payload)

other header fields

TCP/UDP segment format

Connectionless demultiplexing

recall: created socket has host-local port #:

DatagramSocket mySocket1 = new DatagramSocket(12534);

when host receives UDP segment: checks destination port # in segment

directs UDP segment to socket with that port #

recall: when creating datagram to send into UDP socket, must specify

destination IP address

destination port #IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest

Connectionless demux: example

DatagramSocket serverSocket = new DatagramSocket

(6428);

transport

application

physical

link

network

P3transport

application

physical

link

network

P1

transport

application

physical

link

network

P4

DatagramSocket mySocket1 = new DatagramSocket (5775);

DatagramSocket mySocket2 = new DatagramSocket (9157);

source port: 9157dest port: 6428

source port: 6428dest port: 9157

source port: ?dest port: ?

source port: ?dest port: ?

Connection-oriented demux

TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number

demux: receiver 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

Connection-oriented demux: example

transport

application

physical

link

network

P3transport

application

physical

link

P4

transport

application

physical

link

network

P2

source IP,port: A,9157dest IP, port: B,80

source IP,port: B,80dest IP,port: A,9157

host: IP

address A

host: IP

address C

network

P6P5P3

source IP,port: C,5775dest IP,port: B,80


three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets

server: IP

address B

Connection-oriented demux: example

transport

application

physical

link

network

P3transport

application

physical

link

transport

application

physical

link

network

P2

source IP,port: A,9157dest IP, port: B,80

source IP,port: B,80dest IP,port: A,9157

host: IP

address A

host: IP

address C

server: IP

address B

network

P3



P4

threaded server

Roadmap








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 use: streaming multimedia apps (loss tolerant, rate sensitive)

RIP SNMP

reliable transfer over UDP: add reliability at application layer

application-specific error recovery!

UDP: segment header

source port #dest port #

32 bits

applicationdata

(payload)

UDP segment format

length checksum

length, in bytes of UDP segment, including header

no connection establishment (which can add delay)

simple: no connection state at sender, receiver

small header size

why is there a UDP?

no congestion control high loss rate

UDP checksum

sender: treat segment contents, including header fields, as sequence of 16-bit integers

checksum: addition (one’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

Internet checksum: exampleexample: add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

wraparound

sumchecksum

Note: when adding numbers, a carryout from the most significant bit needs to be

added to the result

Roadmap








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) inits sender, receiver state before data exchange

flow controlled: sender will not overwhelm receiver

point-to-point: one sender, one receiver

reliable, in-order byte steam:

pipelined: TCP congestion and flow control set window size

TCP segment structure

source port # dest port #

32 bits

applicationdata

(variable length)

sequence number

acknowledgement number

receive window

Urg data pointerchecksum

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)

TCP reliable data transfer TCP creates rdt service on top of IP’s unreliable service pipelined segments cumulative acks single retransmission timer

We have studied the protocols in data link layer Similar

TCP flow control

buffered data

free buffer spacerwnd

RcvBuffer

TCP segment payloads

to application process

receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments RcvBuffer size set via socket options (typical default is 4096 bytes)

many operating systems autoadjust RcvBuffer

sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value

guarantees receive buffer will not overflow

receiver-side buffering

TCP Connection Managementbefore exchanging data, sender/receiver “handshake”:

agree to establish connection (each knowing the other willing to establish connection)

agree on connection parameters

connection state: ESTABconnection variables:

seq # client-to-server server-to-clientrcvBuffer size at server,client

application

network

connection state: ESTABconnection Variables:

seq # client-to-server server-to-clientrcvBuffer size at server,client

application

network

Socket clientSocket = newSocket("hostname","port

number");

Socket connectionSocket = welcomeSocket.accept();

Q: will 2-way handshake always work in network?

retransmitted messages (e.g. req_conn(x)) due to message loss

can’t “see” other side

2-way handshake:

Let’s talk

OKESTAB

ESTAB

choose xreq_conn(x)

ESTAB

ESTABacc_conn(x)

Agreeing to establish a connection

TCP 3-way handshake

SYNbit=1, Seq=x

choose init seq num, xsend TCP SYN msg

ESTAB

SYNbit=1, Seq=yACKbit=1; ACKnum=x+1

choose init seq num, ysend TCP SYNACKmsg, acking SYN

ACKbit=1, ACKnum=y+1

received SYNACK(x) indicates server is live;

send ACK for SYNACK;this segment may contain

client-to-server datareceived ACK(y) indicates client is live

SYNSENT

ESTAB

SYN RCVD

client state

LISTEN

server state

LISTEN

TCP: closing a connection

Connection release is easy but needs care

Asymmetric release is the way the telephone system works:

when one party hangs up, the connection is broken.

Symmetric release treats the connection as two separate unidirectional connections and

requires each one to be released separately.

Asymmetric Release

Abrupt disconnection with loss of data needs better protocol

Symmetric release Symmetric release does the job when each process has a fixed amount of data to send and clearly knows when it has sent it.

One can envision a protocol in which host 1 says ‘‘I am done. Are you done too?’’ If host 2 responds: ‘‘I am done too. Goodbye, the connection can be safely released.’’

Unfortunately, this protocol does not always work: two-army problem.

Two-army problem

Two-army problem A white army is encamped in a valley.

On both surrounding hillsides are blue armies.

The white army is larger than either of the blue armies alone, but together the blue armies are larger than the white army.

If either blue army attacks by itself, it will be defeated, but if the two blue armies attack simultaneously, they will be victorious.

Two-army problem The blue armies want to synchronize their attacks.

However, their only communication medium is to send messengers on foot down into the valley, where they might be captured and the message lost (i.e., they have to use an unreliable communication channel).

The question is: does a protocol exist that allows the blue armies to win?

Two-army problem Answer: no protocol exists that works.

Relevance to connection release substitute ‘‘disconnect’’ for ‘‘attack.’’

If neither side is prepared to disconnect until it is convinced that the other side is prepared to disconnect too, the disconnection will never happen.

solution to close a TCP connection

In practice, we can avoid this quandary by foregoing the need for agreement and letting each side independently decide when it is done.

client, server each close their side of connection send TCP segment with FIN bit = 1

respond to received FIN with ACK on receiving FIN, ACK can be combined with own FIN

While this protocol is not infallible, it is usually adequate.

FIN_WAIT_2

CLOSE_WAIT

FINbit=1, seq=y

ACKbit=1; ACKnum=y+1

ACKbit=1; ACKnum=x+1 wait for server

close

can stillsend data

can no longersend data

LAST_ACK

CLOSED

TIMED_WAIT

timed wait

CLOSED

solution to close a TCP connection

FIN_WAIT_1 FINbit=1, seq=xcan no longer

send but can

receive data

clientSocket.close()

client state server state

ESTABESTAB

transport layer abusayeed saifullah cs 5600 computer networks these slides are adapted from kurose...

Documents

transport layer segment

transport layer services

hoststransport layer

transport protocol available

dest port

dest ip

network layernetwork

ip addresses port numbers