Chapter 3 T LTransport Layer - Redes de Computadores

1

Fundamentals of Data Communication and Networking

Chapter 3T LTransport Layer

Computer Networking: A Top Down Approach F t i th I t t

A note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:

Transport Layer 3-1

Featuring the Internet

Jim Kurose, Keith RossAddison-Wesley

following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.

Thanks and enjoy! JFK/KWR

All material copyright 1996-2011J.F Kurose and K.W. Ross, All Rights Reserved

Chapter 3: Transport LayerOur goals: understand principles

b h d learn about transport

l t l i th behind transport layer services: multiplexing/demultipl

exing reliable data transfer flow control congestion control

layer protocols in the Internet: UDP: connectionless

transport TCP: connection-oriented

transport TCP congestion control

Transport Layer 3-2

congestion control CP congest on control

2

Chapter 3 outline

3.1 Transport-layer services

3.5 Connection-oriented transport: TCPservices

3.2 Multiplexing and demultiplexing

3.3 Connectionless transport: UDP

3.4 Principles of reliable data transfer

transport TCP segment structure reliable data transfer flow control connection management

3.6 Principles of congestion control

Transport Layer 3-3

reliable data transfer congest on control

Transport services and protocols provide logical communication

between app processes running on different hosts

applicationtransportnetworkdata linkphysical

networkd t linkrunning 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

physical

application

networkdata linkphysical



data linkphysicalnetwork

data linkphysical

Transport Layer 3-4

segments into messages, passes to app layer

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


3

Transport vs. network layer

network layer: logical communication communication between hosts

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

network layer services

Transport Layer 3-5

y

Internet transport-layer protocols

reliable, in-order delivery (TCP)

l


networkd t link

congestion control flow control connection setup

unreliable, unordered delivery: UDP no-frills extension of

“best effort” IP

physical

application




data linkphysicalnetwork

data linkphysical

Transport Layer 3-6

best-effort IP services not available:

delay guarantees bandwidth guarantees


4

Chapter 3 outline








Transport Layer 3-7


Multiplexing/demultiplexing

delivering received segmentsto correct socket

Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data with h d (l d f

Multiplexing at send host:

application

transport

P1 application

transport

t k

application

transport

P2P3 P4P1

= process= socket

to correct socket header (later used for demultiplexing)

Transport Layer 3-8

network

link

physical

network

link

physical

network

link

physical

host 1 host 2 host 3

5

How demultiplexing works host receives IP datagrams

each datagram has source IP address, destination IP dd source port # dest port #

32 bits

address each datagram carries 1

transport-layer segment each segment has source,

destination port number host uses IP addresses & port

numbers to direct segment to

source port # dest port #

applicationdata

other header fields

Transport Layer 3-9

appropriate socket (message)

TCP/UDP segment format

Chapter 3 outline








Transport Layer 3-10


6

UDP: User Datagram Protocol [RFC 768]

“no frills,” “bare bones” Internet transport protocol

Why is there a UDP?protocol

“best effort” service, UDP segments may be: lost delivered out of order

to app connectionless:

no connection establishment (which can add delay)

simple: no connection state at sender, receiver

small segment header no congestion control: UDP


no handshaking between UDP sender, receiver

each UDP segment handled independently of others

gcan blast away as fast as desired

UDP: more often used for streaming

multimedia apps loss tolerant source port # dest port #

32 bits

loss tolerant rate sensitive

other UDP uses DNS SNMP

reliable transfer over UDP: add reliability at


Applicationdata

length checksumLength, in

bytes of UDPsegment,including

header


add reliability at application layer application-specific

error recovery!

(message)

UDP segment format

7

UDP checksumGoal: detect “errors” (e.g., flipped bits) in transmitted

segment

Sender: treat segment contents

as sequence of 16-bit integers

checksum: addition (1’s complement sum) of

Receiver: compute checksum of

received segment check if computed checksum

equals checksum field value: NO - error detected


p )segment contents

sender puts checksum value into UDP checksum field

NO error detected YES - no error detected.

But maybe errors nonetheless? More later ….

Chapter 3 outline










8

Rdt2.0: channel with bit errors

underlying channel may flip bits in packet checksum to detect bit errors

th ti h t f the question: how to recover from errors: 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

new mechanisms in rdt2.0 (beyond rdt1.0):


new mechanisms in rdt2.0 (beyond rdt1.0): error detection receiver feedback: control msgs (ACK,NAK) rcvr->sender

rdt2.0 has a fatal flaw!

What happens if ACK/NAK corrupted?

Handling duplicates: sender retransmits current ACK/NAK corrupted?

sender doesn’t know what happened at receiver!

can’t just retransmit: possible duplicate

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

9

rdt2.2: a NAK-free protocol

same functionality as rdt2.1, using ACKs only instead of NAK receiver sends ACK for last pkt 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


rdt3.0: channels with errors and loss

New assumption:underlying channel can

Approach: sender waits “reasonable” amount of underlying channel can

also lose packets (data or ACKs) checksum, seq. #, ACKs,

retransmissions will be of help, but not enough

reasonable amount of time for ACK

retransmits if no ACK received in this time

if pkt (or ACK) just delayed (not lost): retransmission will be

duplicate but use of seq


duplicate, but use of seq. #’s already handles this

receiver must specify seq # of pkt being ACKed

requires countdown timer

10

Pipelined protocolsPipelining: sender allows multiple, “in-flight”, yet-to-

be-acknowledged pkts range of sequence numbers must be increased range of sequence numbers must be increased buffering at sender and/or receiver


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

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

11

Chapter 3 outline










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

full duplex data: bi-directional data flow

point-to-point: one sender, one receiver f

in same connection MSS: maximum segment

size connection-oriented:

handshaking (exchange of control msgs) init’s sender receiver state

, reliable, in-order byte

steam: no “message boundaries”

pipelined: TCP congestion and flow

control set window size


sender, receiver state before data exchange

flow controlled: sender will not

overwhelm receiver

send & receive buffers

socketdoor

TCPsend buffer

TCPreceive buffer

socketdoor

segment

applicationwrites data

applicationreads data

12

TCP segment structure


32 bits

sequence number

URG: urgent data (generally not used)

ACK ACK #

countingby bytes of dataq m

acknowledgement numberReceive windowUrg data pnterchecksum

FSRPAUheadlen

notused

Options (variable length)

ACK: ACK #valid

PSH: push data now(generally not used)

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

d )

# bytes rcvr willingto accept

of data(not segments!)


applicationdata

(variable length)

commands)

Internetchecksum

(as in UDP)

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

byte stream “number” of first

Host A Host B

Usertbyte in segment’s

dataACKs:

seq # of next byte expected from other side

cumulative ACK

types‘C’

host ACKsreceipt

host ACKsreceipt of‘C’, echoes

back ‘C’


cumulat ve A KQ: how receiver handles

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

say, - up to implementor

pof echoed

‘C’

timesimple telnet scenario

13

TCP Round Trip Time and Timeout

Q: how to set TCP timeout value?l h RTT

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

segment transmission until ACK longer than RTT but RTT varies

too short: premature timeout unnecessary

retransmissions too long: slow reaction

segment transmission until ACK receipt ignore retransmissions

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

measurements, not just current SampleRTT


to segment loss current SampleRTT

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

350

200

250

300

RTT

(mill

isec

onds

)


100

150

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

time (seconnds)

SampleRTT Estimated RTT

14

TCP Round Trip Time and Timeout

Setting the timeout EstimtedRTT plus “safety margin”

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

EstimatedRTT:

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

(typically = 0 25)


TimeoutInterval = EstimatedRTT + 4*DevRTT

(typically, = 0.25)

Then set timeout interval:

Chapter 3 outline










15

TCP reliable data transfer

TCP creates rdt service on top of IP’s

Retransmissions are triggered by:service on top of IP s

unreliable service Pipelined segments Cumulative acks TCP uses single

retransmission timer

triggered by timeout events duplicate acks

Initially consider simplified TCP sender: ignore duplicate acks ignore flow control,


ignore flow control, congestion control

TCP sender events:data rcvd from app: Create segment with

seq #

timeout: retransmit segment

that caused timeoutq seq # is byte-stream

number of first data byte in segment

start timer if not already running (think of timer as for oldest

restart timerAck rcvd: If acknowledges

previously unacked segments update what is known to


unacked segment) expiration interval: TimeOutInterval

update what is known to be acked

start timer if there are outstanding segments

16

Chapter 3 outline










TCP Flow Control

receive side of TCP connection has a

sender won’t overflowreceiver’s buffer by

transmitting too much

flow control

connection has a receive buffer:

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

transmitting too much,too fast


receiving app s drain rate

app process may be slow at reading from buffer

17

TCP Flow control: how it works Rcvr advertises spare

room by including value f i

(Suppose TCP receiver discards out-of-order segments)

i b ff

of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesn’t overflow


spare room in buffer= RcvWindow

= RcvBuffer-[LastByteRcvd -LastByteRead]

Chapter 3 outline










18

TCP Connection ManagementRecall: TCP sender, receiver

establish “connection” before exchanging data segments

Three way handshake:Step 1: client host sends TCP

SYN segment to server initialize TCP variables:

seq. #s buffers, flow control

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

Socket clientSocket = new Socket("hostname","port

specifies initial seq # no data

Step 2: server host receives SYN, replies with SYNACK segment server allocates buffers s ifi s s i iti l


number");

server: contacted by clientSocket connectionSocket = welcomeSocket.accept();

specifies server initial seq. #

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

TCP Connection Management (cont.)

Closing a connection: client server

client closes socket:clientSocket.close();

Step 1: client end system sends TCP FIN control segment to server

St 2

close

close

it


Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. closed

tim

ed w

ai

19

TCP Connection Management (cont.)

Step 3: client receives FIN, replies with ACK

client serverreplies with ACK.

Enters “timed wait” -will respond with ACK to received FINs

Step 4: server, receives ACK. Connection closed.

closing

closing

it


Note: with small modification, can handle simultaneous FINs.

closed

tim

ed w

aiclosed

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle


20

Chapter 3 outline










Principles of Congestion Control

Congestion: informally: “too many sources sending too much informally: too many sources sending too much

data too fast for network to handle” different from flow control! manifestations:

lost packets (buffer overflow at routers) long delays (queueing in router buffers)


g y (q g ff ) a top-10 problem!

21

Approaches towards congestion control

E d d ti N t k i t d

Two broad approaches towards congestion control:

End-end congestion control:

no explicit feedback from network

congestion inferred from end-system observed loss, delay

Network-assisted congestion control:

routers provide feedback to end systems single bit indicating

congestion (SNA, DECbit, TCP/IP ECN,


y approach taken by TCP ATM)

explicit rate sender should send at

Chapter 3: Summary principles behind transport

layer services:l i l i multiplexing,

demultiplexing reliable data transfer flow control congestion control

instantiation and

Next: leaving the network

“edge” (application


instantiation and implementation in the Internet UDP TCP

edge (application, transport layers)

into the network “core”

Documents

Chapter 3 T LTransport Layer - Redes de Computadores