Transp Layer1

7/29/2019 Transp Layer1

1/35

1

Transport LayerTransport Layer


2/35

Transport LayerTransport Layer

Goals:

understand principles behindtransport layer services:

-multiplexing/demultiplexing-reliable data transfer-flow control-congestion control

learn about transport layerprotocols in the Internet:UDP: connectionless

transportTCP: connection-orientedtransportTCP congestion control


3/35

Transport services and protocolsTransport services and protocols

- provide logical communicationbetween app processes runningon different hosts- transport protocols run in endsystems

send side: breaks app messagesinto segments, passes tonetwork layerrcv side: reassembles segmentsinto messages, passes to applayer- more than one transportprotocol available to appsInternet: TCP and UDP

application

transport

network

data link

physical

application

transport

networkdata link

physical

network

data link

physical

networkdata link

physical

network

data link

physical

network

data link

physicalnetwork

data link

physical

logicalend-endtransport


4/35

Transport vs. network layerTransport vs. network layer

-network layer:logicalcommunication betweenhosts

-transport layer:logicalcommunication between

processes

relies on, enhances,network layer services

application

transport

network

data link

physical

application

transport

networkdata link

physical

network

data link

physical

networkdata link

physical

network

data link

physical

network

data link

physicalnetwork

data link

physical


5/35

Multiplexing/demultiplexingMultiplexing/demultiplexing

application

transport

network

link

physical

P1 application

transport

network

link

physical

application

transport

network

link

physical

P2P3 P4

P1

host 1 host 2host 3

= process= socket

delivering received segmentsto correct socket

Demultiplexing at rcv host: gathering data from multiplesockets, enveloping data withheader (later used fordemultiplexing)

Multiplexing at send host:


6/35

How demultiplexing worksHow demultiplexing works

-host receives IP datagrams-each datagram has sourceIP address, destination IPaddress-each datagram carries 1

transport-layer segment-each segment has source,destination port number-host uses IP addresses &port numbers to direct

segment to appropriatesocket

source port # dest port #

32 bits

application

data

(message)

other header fields

TCP/UDP segment format


7/35

Connectionless demultiplexingConnectionless demultiplexing

Create sockets with port numbers:DatagramSocket mySocket1 = new

DatagramSocket(12534);

DatagramSocket mySocket2 = new

DatagramSocket(12535);

UDP socket identified by two-tuple:

(dest IP address, dest port number)

When host receives UDPsegment:

checks destination port numberin segmentdirects UDP segment to socketwith that port number


8/35

Connectionless demux (cont)Connectionless demux (cont)

DatagramSocket serverSocket = new DatagramSocket(6428);

ClientIP:B

P2

client

IP: A

P1P1P3

server

IP: C

SP: 6428

DP: 9157

SP: 9157

DP: 6428

SP: 6428

DP: 5775

SP: 5775

DP: 6428

SP provides return address


9/35

Connection-oriented demuxConnection-oriented demux

TCP socket identified by4-tuple:source IP addresssource port number

dest IP addressdest port number

recv host uses all fourvalues to direct segment

to appropriate socket

Server host may supportmany simultaneous TCPsockets:each socket identified by its own

4-tupleWeb servers havedifferent sockets for eachconnecting clientnon-persistent HTTP will havedifferent socket for eachrequest


10/35

UDP: User Datagram ProtocolUDP: User Datagram Protocol [RFC 768][RFC 768]

-best effort service, UDPsegments may be:Lostdelivered out of order to appconnectionless:

-no handshaking between UDPsender, receiver-each UDP segment handledindependently of others

Why is there a UDP?

no connection establishment(which can add delay)

simple: no connection state atsender, receiver

small segment headerno congestion control: UDP

can blast away as fast asdesired


11/35

UDP: moreUDP: more

-often used for streamingmultimedia appsloss tolerantrate sensitive

-other UDP usesDNSSNMP-reliable transfer over UDP:add reliability at applicationlayer-application-specific errorrecovery!


32 bits

Application

data

(message)

UDP segment format

length checksum

Length, in

bytes of UDP

segment,

includingheader


12/35

UDP checksumUDP checksum

Sender:

treat segment contents assequence of 16-bitintegers

checksum: addition (1scomplement sum) ofsegment contents

sender puts checksum valueinto UDP checksum field

Receiver:

compute checksum of receivedsegmentcheck if computed checksum

equals checksum field value:NO - error detected

YES - no error detected. Butmaybe errors nonetheless?More later .

Goal: detect errors (e.g., flipped bits) in transmittedsegment


13/35

Internet Checksum ExampleInternet Checksum ExampleNote

When adding numbers, a carryout from the mostsignificant bit needs to be added to the result

Example: add two 16-bit integers

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

1 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 0

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

wraparound

sum

checksum


14/35

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

full duplex data:bi-directional data flow insame connectionMSS: maximum segment size

connection-oriented:handshaking (exchange ofcontrol msgs) inits sender,receiver state before dataexchange

flow controlled:sender will not overwhelmreceiver

point-to-point:one sender, one receiver

reliable, in-order bytesteam:

no message boundariespipelined:TCP congestion and flow controlset window size

send & receive buffers

s o c k e t

d o o r

T C P

s e n d b u f f e r

T C P

r e c e i v e b u f f e r

s o c k e t

d o o r

s e g m e n t

a p p l i c a t i o n

w r i t e s d a t aa p p l i c a t i o n

r e a d s d a t a


15/35

TCP segment structureTCP segment structure


32 bits

applicationdata

(variable length)

sequence number

acknowledgement number

Receive window

Urg data pnterchecksum

FSRPAUhead

len

not

used

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)

# bytesrcvr willing

to accept

counting

by bytes

of data

(not segments!)

Internet

checksum

(as in UDP)


16/35

TCP seq. #s and ACKsTCP seq. #s and ACKs

Seq. #s:byte stream number offirst byte in segmentsdataACKs:

seq # of next byteexpected from other sidecumulative ACKQ: how receiver handles

out-of-order segments

A: TCP spec doesnt say, -up to implementor

Host A Host B

Seq=42,ACK=79,data=C

Seq=79,A

CK=43,data=C

Seq=43,ACK=80

User

types

C

host ACKs

receipt

of echoedC

host ACKs

receipt of

C, echoes

back C

timesimple telnet scenario


17/35

TCP Round Trip Time and TimeoutTCP Round Trip Time and Timeout

Q: how to set TCPtimeout value?

longer than RTTbut RTT varies

too short: premature

timeoutunnecessaryretransmissionstoo long: slow reaction to

segment loss

Q: how to estimate RTT?SampleRTT: measured time from

segment transmission until ACKreceipt

ignore retransmissions

SampleRTTwill vary, wantestimated RTT smoother

average several recentmeasurements, not just currentSampleRTT


18/35

TCP Round Trip Time and TimeoutTCP Round Trip Time and Timeout

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT Exponential weighted moving average influence of past sample decreases exponentially fast

typical value: =

0.125


19/35

Example RTT estimation:Example RTT estimation:RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT(milliseconds)

SampleRTT Estimated RTT


20/35

TCP Round Trip Time andTCP Round Trip Time andTimeoutTimeout

Setting the timeoutEstimtedRTTplus safety marginlarge variation in EstimatedRTT -> larger safety margin

first estimate of how much SampleRTT deviates fromEstimatedRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|(typically, = 0.25)Then set timeout interval:


21/35

TCP reliable data transferTCP reliable data transfer

-TCP creates rdt service ontop of IPs unreliableservice

-Pipelined segments

-Cumulative acks-TCP uses singleretransmission timer

Retransmissions are triggeredby:

-timeout events-duplicate acks

Initially consider simplifiedTCP sender:-ignore duplicate acks-ignore flow control, congestioncontrol


22/35

TCP sender events:TCP sender events:data rcvd from app:

Create segment with seq #seq # is byte-stream

number of first databyte in segment

start timer if not alreadyrunning (think of timeras for oldest unackedsegment)

expiration interval:

TimeOutInterval

timeout:

retransmit segment thatcaused timeout

restart timer

Ack rcvd:

If acknowledges previouslyunacked segments

update what is known to be ackedstart timer if there areoutstanding segments


23/35

TCP: retransmission scenariosTCP: retransmission scenarios

Host A

Seq=100,20bytesdata

ACK=100

timepremature timeout

Host B

Seq=92,8bytesdata

ACK=120

Seq=92,8bytesdataSeq=92tim

eout

ACK=12

0

Host A

Seq=92,8bytesdata

ACK=10

0

loss

timeo

ut

lost ACK scenario

Host B

X

Seq=92,8bytesdata

ACK=100

time

Seq=92

timeout

SendBase

= 100

SendBase

= 120

SendBase

= 120

Sendbase

= 100


24/35

TCP retransmission scenarios (more)TCP retransmission scenarios (more)

Host A

Seq=92,8bytesdata

ACK=10

0

loss

timeo

ut

Cumulative ACK scenario

Host B

X

Seq=100,20bytesdata

ACK=12

0

time

SendBase

= 120


25/35

Fast RetransmitFast Retransmit

Time-out period oftenrelatively long:-long delay before resendinglost packet

Detect lost segments viaduplicate ACKs.-Sender often sends manysegments back-to-back-If segment is lost, there will

likely be many duplicate ACKs.

If sender receives 3 ACKsfor the same data, itsupposes that segment afterACKed data was lost:

fast retransmit: resend segmentbefore timer expires


26/35

TCP Flow ControlTCP Flow Control

receive side of TCPconnection has a receivebuffer:

speed-matching service:matching the send rateto the receiving appsdrain rate

app process may beslow at reading frombuffer

sender wont overflowreceivers buffer bytransmitting too much,too fast

flow control


27/35

TCP Flow control: how itTCP Flow control: how itworksworks

(Suppose TCP receiver discardsout-of-order segments)

spare room in buffer

= RcvWindow

= RcvBuffer-[LastByteRcvd -

LastByteRead]

Rcvr advertises spare roomby including value ofRcvWindow in segments

Sender limits unACKed datato RcvWindow

guarantees receive buffer doesntoverflow


28/35

TCP Connection ManagementTCP Connection Management

Recall:TCP sender, receiverestablish connection beforeexchanging data segments

initialize TCP variables:seq. #s buffers, flow controlinfo (e.g. RcvWindow)client: connection initiator

Socket clientSocket = new

Socket("hostname","port

number");

server: contacted by client

Socket connectionSocket =

welcomeSocket.accept();

Three way handshake:

Step 1:client host sends TCPSYN segment to server

specifies initial seq #no data

Step 2:server host receivesSYN, replies with SYNACKsegment

server allocates buffersspecifies server initial seq. #

Step 3: client receives SYNACK,replies with ACK segment,which may contain data


29/35

TCP Connection Management (cont.)TCP Connection Management (cont.)

Closing a connection:

client closes socket:clientSocket.close();

Step 1:client end systemsends TCP FIN controlsegment to server

Step 2:server receives

FIN, replies with ACK.Closes connection, sendsFIN.

client

FIN

server

ACK

ACK

FIN

close

close

closed

timedwait


30/35

TCP Connection Management (cont.)TCP Connection Management (cont.)

Step 3:client receives FIN,replies with ACK.

Enters timed wait - willrespond with ACK to received

FINs

Step 4:server, receivesACK. Connection closed.

Note:with smallmodification, can handlesimultaneous FINs.

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

timedwait

closed


31/35

TCP Connection Management (cont)TCP Connection Management (cont)

TCP client

lifecycle

TCP server

lifecycle


32/35

Congestion:Congestion:-informally: too many sources sending too much data toofast for networkto handle

-different from flow control!

-manifestations:

+lost packets (buffer overflow at routers)

+long delays (queueing in router buffers)

Principles of Congestion ControlPrinciples of Congestion Control


33/35

Causes/costs of congestion: scenario 1Causes/costs of congestion: scenario 1two senders, tworeceiversone router, infinitebuffers

no retransmission

large delays when

congestedmaximumachievablethroughput

unlimited shared

output link buffers

Host A

in : original data

Host B

out


34/35

Causes/costs of congestion: scenario 2Causes/costs of congestion: scenario 2

-one router, finitebuffers-sender retransmission of lost packet

finite shared output

link buffers

Host

A

in : original data

Host B

out

'in : original data, plus

retransmitted data


35/35

Causes/costs of congestion: scenario 3Causes/costs of congestion: scenario 3

four sendersmultihop pathstimeout/retransmit

inQ:what happens asand increase ?in

finite shared

output link

buffers

Host Ain : original data

Host B

out

'in : original data, plus

retransmitted data

Date post:	04-Apr-2018
Category:	Documents
Upload:	haneesha-muddasani
View:	228 times
Download:	0 times

Transp Layer1

Documents