Chapter 3 Transport Layer TCP: connection oriented UDP: connectionless application presentation...

Chapter 3Transport Layer

TCP: connection orientedUDP: connectionless

application

presentation

session

transport

network

link

physical

Transport Layer: copyright J.F Kurose and K.W. Ross 3-2

Transport services and protocols 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

transportnetworkdata linkphysical

application


logical end-end transport

04/18/23

HtHn M

segment Ht

datagramHtHnHl M

message M

Ht M

Hn

frame


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

application

transportnetworkdata linkphysical network

data linkphysical

networkdata linkphysical





application


logical end-end transport

04/18/23


Recall

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

receiving host uses all four values to direct segment to appropriate socket

Muxing/Demuxing

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

04/18/23

1. Create a socket with the socket() system call2. Bind socket to address using the bind() (port and ip

address)3. Listen for connections with the listen() system call4. Accept a connection with the accept() system call. 5. Send and receive data over socket returned by accept

1. Create a socket with the socket() system call2. Connect the socket to the address of the server using the

connect() system call3. Send and receive data.


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

Why is there a UDP? no connection

establishment (which can add delay)

simple: no connection state at sender, receiver

small segment header no congestion control:

UDP can blast away as fast as desired

04/18/23

Ports

Well-known ports 0 to 1023 are the well-known

ports. FTP 20/21, HTTP 80, Mail 25

Registered ports 1024 to 49151 are the

registered ports and are assigned by Internet Assigned Numbers Authority (IANA)

Dynamic, private or ephemeral ports 49152–65535

04/18/23 Application Layer: copyright J.F Kurose and K.W. Ross 6

0Well-known

1023

1024Registered

49151

49152Private65535


UDP: more

often used for streaming multimedia apps loss tolerant rate sensitive

other UDP uses DNS SNMP

reliable transfer over UDP: add reliability at application layer application-specific

error recovery!

source port # dest port #

32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header

04/18/23


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.

But maybe errors nonetheless? More later ….

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

04/18/23


Internet Checksum Example Note

When adding numbers, a carryout from the most significant 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 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

04/18/23


TCP

04/18/23

How ensure reliable data transfer?

Could acknowledge each packet Based on old character-based protocols

ASCII/EBCDIC (ACK = 06/2E, NAK = 15/3D) Acknowledgements (ACKs): receiver

explicitly tells sender that pkt received OK Negative acknowledgements (NAKs):

receiver explicitly tells sender that pkt had errors

sender retransmits pkt on receipt of NAK In packet might be a bit in the TCP

header

04/18/23 Transport Layer: copyright J.F Kurose and K.W. Ross 3-11


ACK/NAK has a fatal flaw!

What happens if ACK/NAK corrupted?

sender doesn’t know what happened at receiver!

can’t just retransmit: possible duplicate

Handling duplicates: sender retransmits current

pkt if ACK/NAK garbled sender adds sequence

number to each pkt receiver discards (doesn’t

deliver up) duplicate pkt

Sender sends one packet, then waits for receiver response

stop and wait

04/18/23

Efficient?

Could go NAK-free protocol instead of NAK, receiver sends ACK for

last pkt received OK receiver must explicitly include seq # of pkt

being ACKed duplicate ACK at sender results in same

action as NAK: retransmit current pkt



Cuts out one exchange: efficient?

04/18/23


Pipelined protocols

Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver

Two generic forms of pipelined protocols: go-Back-N, selective repeat

04/18/23


Pipelining Protocols

Go-back-N: overview sender: up to N

unACKed pkts in pipeline

receiver: only sends cumulative ACKs doesn’t ACK pkt if

there’s a gap sender: has timer for

oldest unACKed pkt if timer expires:

retransmit all unACKed packets

Selective Repeat: overview

sender: up to N unACKed packets in pipeline

receiver: ACKs individual pkts

sender: maintains timer for each unACKed pkt if timer expires:

retransmit only unACKed packet

04/18/23


Go-Back-NSender: k-bit seq # in pkt header “window” of up to N, consecutive unACKed pkts allowed

ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs (see receiver)

timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq # pkts in window

04/18/23


GBN inaction

04/18/23


Selective Repeat

receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order

delivery to upper layer

sender only resends pkts for which ACK not received sender timer for each unACKed pkt

sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts

04/18/23


Selective repeat: sender, receiver windows

04/18/23


Selective repeat in action

04/18/23


TCP seq. #’s and ACKsSeq. #’s:

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

ACKs: seq # of next byte

expected from other side

cumulative ACKQ: how receiver handles

out-of-order segments A: TCP spec doesn’t

say, - up to implementer

Host A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of

‘C’, echoesback ‘C’

timesimple telnet scenario

04/18/23

Full DuplexFull Duplex


TCP segment structure

source port # dest port #

32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberReceive 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)

04/18/23

length


TCP Round Trip Time and TimeoutQ: how to set TCP

timeout value? longer than RTT

but RTT varies too short: premature

timeout unnecessary

retransmissions too long: slow

reaction to segment loss

Q: how to estimate RTT? SampleRTT: measured time

from segment transmission until ACK receipt ignore retransmissions

SampleRTT will vary, want estimated RTT “smoother” average several recent

measurements, not just current SampleRTT

04/18/23


TCP Round Trip Time and TimeoutEstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

Exponential weighted moving average influence of past sample decreases exponentially fast typical value: = 0.125

04/18/23


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

(mill

isec

onds

)

SampleRTT Estimated RTT

04/18/23


TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus “safety margin”

large variation in EstimatedRTT -> larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|

(typically, = 0.25)

Then set timeout interval:

04/18/23


How does TCP ACK [RFC 1122, RFC 2581]

Event at Receiver

Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed

Arrival of in-order segment withexpected seq #. One other segment has ACK pending

Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected

Arrival of segment that partially or completely fills gap

TCP Receiver action

Delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK

Immediately send single cumulative ACK, ACKing both in-order segments

Immediately send duplicate ACK, indicating seq. # of next expected byte

Immediate send ACK, provided thatsegment starts at lower end of gap

04/18/23


Host A

tim

eout

Host B

time

X

resend seq X2

seq # x1seq # x2seq # x3seq # x4seq # x5

ACK x1

ACK x1ACK x1ACK x1

tripleduplicate

ACKs

04/18/23

Fast retransmit time-out period

often relatively long: long delay before

resending lost packet

detect lost segments via duplicate ACKs. sender often sends

many segments back-to-back

if segment is lost, there will likely be many duplicate ACKs for that segment


TCP Flow Control

receive side of TCP connection has a receive buffer:

speed-matching service: matching send rate to receiving application’s drain rate

app process may be slow at reading from buffer

sender won’t overflow

receiver’s buffer bytransmitting too

much, too fast

flow control

IPdatagrams

TCP data(in buffer)

(currently)unused buffer

space

applicationprocess

04/18/23


TCP congestion control: goal: TCP sender should transmit as fast as possible, but without congesting network

Q: how to find rate just below congestion level

decentralized: each TCP sender sets its own rate, based on implicit feedback: ACK: segment received (a good thing!), network not congested, so increase sending

rate lost segment: assume loss due to congested network, so decrease sending rate

04/18/23


TCP congestion control: bandwidth probing

“probing for bandwidth”: increase transmission rate on receipt of ACK, until eventually loss occurs, then decrease transmission rate continue to increase on ACK, decrease on loss (since available bandwidth

is changing, depending on other connections in network)

ACKs being received, so increase rate

X

X

XX

Xloss, so decrease rate

send

ing r

ate

time

TCP’s“sawtooth”behavior

04/18/23

The End


Chapter 3 Transport Layer TCP: connection oriented UDP: connectionless application presentation...

Documents

Transcript of Chapter 3 Transport Layer TCP: connection oriented UDP: connectionless application presentation...