1 Vad TCP mste klara Koppla ihop mnga olika maskiner Behov av - - PDF document

1

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Last time: Transport 1

transport layer services multiplexing/demultiplexing connectionless transport: UDP principles of reliable data transfer

timer sequence number acknowledgement negative acknowledgement window, pipelining

sliding window protocols

go-back-N selective repeat 16/4-07 Datakommunikation - Jonny Pettersson, UmU

Transport 2

connection-oriented transport: TCP

reliable transfer flow control connection management

principles of congestion control TCP congestion control

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Transmission Control Protocol(TCP)

Definierar säker överföring i TCP/IP

Internet genom att bland annat definiera

Formen på paket och ackar Funktioner som kan användas för att se till att

data anländer korrekt

Hur TCP skiljer på flera mottagare inom en

maskin

Hur kommunikationen initieras och avslutas

VIKTIGT!

TCP är ett protokoll, ej en mjukvara

2

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Vad TCP måste klara

Koppla ihop många olika maskiner

Behov av explicit upp- och nedkoppling

Hantera varierande RTT

Behov av adaptiv timeout för omsändning

Hantera långa fördröjningar i nätet

Behov av hantering av sent anländande paket TTL

Hantera olika kapaciteter hos mottagare

Behov av att kunna anpassa till olika noders resurser

Hantera olika nätverkskapaciteter

Behov av att hantera trafikstockningar på nätet 16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP - Överblick

Kopplingsorienterat Byte-stream

app skriver bytes TCP sänder segment app läser bytes

Pipeline

Application process Write bytes TCP Send buffer Segment Segment Segment Transmit segments Application process Read bytes TCP Receive buffer … … …

Full duplex Flow control: Så sändaren

inte dränker mottagaren

Congestion control: Så

sändaren inte dränker nätverket

RFCs: 793, 1122, 1323, 2018, 2581

16/4-07 Datakommunikation - Jonny Pettersson, UmU

När skickas segment?

Tre sätt att trigga en sändning

MSS (Maximum Segment Size), oftast lika med

MTU (Maximum Transfer Unit) för lokala nätverket

Push operation från applikationen Timeout

3

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Portar och kopplingar

TCP använder portar på ett mer

komplicerat sätt än UDP

Flera kopplingar per port TCP identifierar kopplingar som par av

kommunikationspunkter

< SrcPort, SrcIPAddr, DesPort, DesIPAddr >

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Välkända TCP portar

7 - Echo 9 - Discard 21 - FTP 25 - SMTP 79 - Finger

16/4-07

TCP segment structure

source port # dest port #

32 bits

application data (variable length) sequence number acknowledgement number

rcvr window size ptr urgent data checksum

F S R P A U

head 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) # bytes rcvr willing to accept counting by bytes

• f data

(not segments!) Internet Checksum (TCP header + data + pseudo header)

4

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP seq. #’s and ACKs

• Seq. #’s:

byte stream

“number” of first byte in segment’s data ACKs:

seq # of next byte

expected from

• ther side

cumulative ACK

Q: how receiver handles

• ut-of-order segments

A: TCP spec doesn’t

say, - up to implementor

Host A Host B

S e q = 4 2 , A C K = 7 9 , d a t a = ‘ C ’ S e q = 7 9 , A C K = 4 3 , d a t a = ‘ C ’ S e q = 4 3 , A C K = 8

User types ‘C’ host ACKs receipt

• f echoed

‘C’ host ACKs receipt of ‘C’, echoes back ‘C’

time simple telnet scenario

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP reliable data transfer

TCP creates rdt

service on top of IP’s unreliable service

Pipelined segments Cumulative acks TCP uses single

retransmission timer

Retransmissions are

triggered by:

timeout events duplicate acks

Initially consider

simplified TCP sender:

ignore duplicate acks ignore flow control,

congestion control

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP sender events:

data rcvd from app:

Create segment with

seq #

seq # is byte-stream

number of first data byte in segment

start timer if not

already running (think

• f timer as for oldest

unacked segment)

expiration interval:

TimeOutInterval timeout:

retransmit segment

that caused timeout

restart timer

Ack rcvd:

If acknowledges

previously unacked segments

update what is known to

be acked

start timer if there are

• utstanding segments

5 TCP sender

(simplified)

NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */

Comment:

• SendBase-1: last

cumulatively ack’ed byte Example:

• SendBase-1 = 71;

y= 73, so the rcvr wants 73+ ; y > SendBase, so that new data is acked

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP ACK generation [RFC 1122, RFC 2581]

Event at Receiver

Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. # . Gap detected Arrival of segment that partially or completely fills gap

TCP Receiver action

Delayed ACK. Wait up to 500ms for 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 Immediately send ACK, provided that segment starts at lower end of gap

TCP: retransmission scenarios

Host A

S e q = 1 , 2 b y t e s d a t a ACK=100

time premature timeout

Host B

S e q = 9 2 , 8 b y t e s d a t a ACK=120 S e q = 9 2 , 8 b y t e s d a t a Seq=92 timeout ACK=120

Host A

S e q = 9 2 , 8 b y t e s d a t a ACK=100

loss

timeout

lost ACK scenario

Host B

X

S e q = 9 2 , 8 b y t e s d a t a ACK=100

time

Seq=92 timeout

SendBase = 100 SendBase = 120 SendBase = 120 Sendbase = 100

6

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP retransmission scenarios (more)

Host A

S e q = 9 2 , 8 b y t e s d a t a ACK=100

loss

timeout

Cumulative ACK scenario

Host B

X

S e q = 1 , 2 b y t e s d a t a ACK=120

time

SendBase = 120

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP Flow Control

receiver: explicitly informs sender of (dynamically changing) amount of free buffer space

RcvWindow field in

TCP segment sender: keeps the amount

• f transmitted,

unACKed data less than most recently received RcvWindow sender won’t overrun receiver’s buffers by transmitting too much, too fast

flow control

receiver buffering

RcvBuffer = size or TCP Receive Buffer RcvWindow = amount of spare room in Buffer 16/4-07 Datakommunikation - Jonny Pettersson, UmU

Tillförlitlig och ordnad leverans

Sändaren

LastByteAcked ≤ LastByteSent LastByteSent ≤ LastByteWritten Buffrar mellan LastByteAcked och LastByteWritten

Sending application LastByteWritten TCP LastByteSent LastByteAcked Receiving application LastByteRead TCP LastByteRcvd NextByteExpected

Mottagaren

LastByteRead < NextByteExpected NextByteExpected ≤ LastByteRcvd + 1 Buffrar mellan LastByteRead och LastByteRcvd

7

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Flow Control - Mottagaren

Hos mottagaren

LastByteRcvd - LastByteRead ≤ RcvBuffer RcvWindow = RcvBuffer - (LastByteRcvd -

LastByteRead)

Sending application LastByteWritten TCP LastByteSent LastByteAcked Receiving application LastByteRead TCP LastByteRcvd NextByteExpected

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Flow Control - Sändaren

Hos sändaren

LastByteSent - LastByteAcked ≤ RcvWindow EffectiveWindow = RcvWindow - (LastByteSent -

LastByteAcked)

LastByteWritten - LastByteAcked ≤ MaxSendBuffer

Sending application LastByteWritten TCP LastByteSent LastByteAcked Receiving application LastByteRead TCP LastByteRcvd NextByteExpected

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Flow Control

Om RcvWindow = 0

Hur får sändaren reda på att den kan sända

igen?

Egentligen ska inga paket skickas Men, sändaren fortsätter att skicka 1-byte

data

• Får reda på när RcvWindow ändras
• Smart sender/dumb receiver

8

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Skydd mot “Wrap Around”

32-bit SequenceNum Det beror av sändhastigheten

Ingen “wrap around” bör ske inom 120 sek

Bandwidth Time Until Wrap Around T1 (1.5 Mbps) 6.4 hours Ethernet (10 Mbps) 57 minutes T3 (45 Mbps) 13 minutes FDDI (100 Mbps) 6 minutes STS-3 (155 Mbps) 4 minutes STS-12 (622 Mbps) 55 seconds STS-24 (1.2 Gbps) 28 seconds

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Håll pipan full

16-bit AdvertisedWindow ger 64KB data Bandwidth Delay x Bandwidth Product T1 (1.5 Mbps) 18KB Ethernet (10 Mbps) 122KB T3 (45 Mbps) 549KB FDDI (100 Mbps) 1.2MB STS-3 (155 Mbps) 1.8MB STS-12 (622 Mbps) 7.4MB STS-24 (1.2 Gbps) 14.8MB

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP Extentions

Implementerat som header option Användandet av extentions avgörs vid

uppkopplingen

Tre extentions

Timestamp: 32-bitars värde, för RTT beräkning Timestamp för skydd mot “wrap around” Skalningsfaktor för RcvWindow

9

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP Round Trip Time and Timeout

Q: how to set TCP timeout value?

longer than RTT

note: RTT will vary

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,

cumulatively ACKed segments

SampleRTT will vary, want

estimated RTT “smoother”

use several recent

measurements, not just current SampleRTT

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP Round Trip Time and Timeout

EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT

exponential weighted moving average influence of given sample decreases exponentially fast typical value of α: 0.125

Setting the timeout

EstimtedRTT plus “safety margin”

large variation in EstimatedRTT -> larger safety margin

Timeout = EstimatedRTT + 4*DevRTT DevRTT = (1-β)*DevRTT +

β*|SampleRTT-EstimatedRTT|

(typically, β = 0.25)

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP Connection Management

Three way handshake

Active participant (client) Passive participant (server) SYN, SequenceNum = x SYN + ACK, SequenceNum = y , ACK, Acknowledgment = y + 1 Acknowledgment = x + 1 allocates buffers allocates buffers

10

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP Connection Management (cont.)

Closing a connection:

client closes socket:

Step 1: client end system

sends TCP FIN control segment to server

Step 2: server receives

FIN, replies with ACK. Closes connection, sends FIN.

client

F I N

server

ACK A C K FIN

close close closed timed wait

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP Connection Management (cont.)

Step 3: client receives FIN,

replies with ACK.

Enters “timed wait” -

will respond with ACK to received FINs

Step 4: server, receives

• ACK. Connection closed.

Note: with small

modification, can handle simultaneous FINs.

client

F I N

server

ACK A C K FIN

closing closing closed timed wait closed

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP tillståndsdiagram

CLOSED LISTEN SYN_RCVD SYN_SENT ESTABLISHED CLOSE_WAIT LAST_ACK CLOSING TIME_WAIT FIN_WAIT_2 FIN_WAIT_1 Passive open Close Send/SYN SYN/SYN + ACK SYN + ACK/ACK SYN/SYN + ACK ACK Close/FIN FIN/ACK Close/FIN FIN/ACK ACK + FIN/ACK Timeout after two segment lifetimes FIN/ACK ACK ACK ACK Close/FIN Close CLOSED Active open/SYN

TCP client lifecycle TCP server lifecycle

11

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Principles of Congestion Control

Congestion:

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)

a top-10 problem!

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Causes/costs of congestion: scenario 1

two senders, two

receivers

• ne router,

infinite buffers

no retransmission large delays

when congested

maximum

achievable throughput

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Causes/costs of congestion: scenario 2

• ne router, finite buffers

sender retransmission of lost packet “costs” of congestion:

more work

(retrans) for given “goodput”

unneeded

retransmissions: link carries multiple copies

• f pkt

no loss ”perfect” retrans ”premature timeout”

12

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Causes/costs of congestion: scenario 3

four senders multihop paths timeout/retransmit

Another “cost” of congestion:

when packet dropped,

any “upstream transmission capacity used for that packet was wasted!

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Approaches towards congestion control

End-end congestion control:

no explicit feedback from

network

congestion inferred from

end-system observed loss, delay

approach taken by TCP

Network-assisted congestion control:

routers provide feedback

to end systems

single bit indicating

congestion (SNA, DECbit, TCP/IP ECN, ATM)

explicit rate sender

should send at

Two broad approaches towards congestion control:

16/4-07 Datakommunikation - Jonny Pettersson, UmU

TCP Congestion Control

Strategi

Skicka paket in i nätverket utan reservation och reagera

på observerade händelser Antag

Best-effort nätverk Självklockande: Varje anländande ACK innebär att ett

nytt paket kan sändas Utmaning

Bestäm kapacitet vid start Anpassa till förändringar i tillgänglig kapacitet

Består av tre delar

AIMD - Additive Increase/Multiplicative Decrease Slow Start Fast Retransmit och Fast Recovery

13

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Additive Increase/Multiplicative Decrease - AIMD

Mål: Anpassa till förändringar i kapacitet Ny variabel: CongWindow

För varje uppkoppling Begränsar hur mycket data en sändare kan ha

utestående oACKat

MaxWindow = Min(CongWindow, RcvWindow) EffectiveWindow = MaxWindow - (LastByteSent- LastByteAcked)

Idé

• Öka CongWindow när congestion går ner
• Minska CongWindow när congestion går upp

16/4-07 Datakommunikation - Jonny Pettersson, UmU

AIMD (forts)

Fråga: Hur lär sig sändaren om nätverket

är överbelastat eller ej?

Svar: En timeout sker

En timeout signalerar att ett paket försvunnit Paket försvinner sällan pga överföringsfel Förlorade paket indikerar överbelastning

16/4-07 Datakommunikation - Jonny Pettersson, UmU

AIMD (forts)

Algoritm

Öka CongWindow med ett MSS

per RTT

Halvera CongWindow när en

timeout sker I praktiken

Öka lite för varje anländ ACK CongWindow += MSS *

(MSS/CongWindow)

Source Destination …

throughput = w * MSS RTT Bytes/sec

14

16/4-07 Datakommunikation - Jonny Pettersson, UmU

AIMD (forts)

Viktigt!

CongWindow minskar snabbare än ökar Nödvändigt villkor för stabilitet i systemet

60 20 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 KB Time (seconds) 70 30 40 50 10 10.0 16/4-07 Datakommunikation - Jonny Pettersson, UmU

Slow Start

Problem: Tar lång tid att komma

upp i “stabil” CongestionWindow

Lösning: Öka fönstret

exponentiellt

Börja med CongWindow = 1 (MSS) Dubbla CongWindow varje RTT

(öka med 1 paket för varje ACK)

Source Destination …

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Slow Start (forts)

Körs vid två tillfällen

Vid start av ny uppkoppling Vid timeout

Definera CongestionThreshold som

halva värdet av det CongWindow som resulterade i congestion

Slow Start till CongestionThreshold,

därefter Additive Increase

15

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Slow Start (forts)

Problem: Förlorar data värt upp till halva

storleken av CongWindow

60 20 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 KB Time (seconds) 70 30 40 50 10 Additive Increase Inga ACK Slow Start Additive Increase 16/4-07 Datakommunikation - Jonny Pettersson, UmU

Timeout

Viktigt med bra timeout mekanism

Timeout: funktion av både medel-RTT och

standardavvikelsen för medel-RTT

Pga kostnaden att mäta varje sändning med en

tillförlitlig klocka, används endast sampling av RTT en gång per RTT med en klocka med grov granularitet

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Fast Retransmit

Problem: Grovkornig klocka

ger lång tid innan timeout

Lösning: Fast Retransmit

Använd “duplicate ACK” När sändaren får tre

“duplicate ACK” triggas

• msändning

20% bättre

genomströmning

Minskar antalet “vanliga”

timeout med hälften

Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Packet 6 Retransmit packet 3 ACK 1 ACK 2 ACK 2 ACK 2 ACK 6 ACK 2 Sender Receiver

16

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Resultat

60 20 1.0 2.0 3.0 4.0 5.0 6.0 7.0 KB 70 30 40 50 10 16/4-07 Datakommunikation - Jonny Pettersson, UmU

Fast Recovery

Fast Recovery

Vid Fast Retransmit, skippa Slow Start och

starta direkt på CongestionThreshold med Additive Increase

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Why is TCP fair?

Two competing sessions:

Additive increase

gives slope of 1, as throughput increases

multiplicative

decrease decreases throughput proportionally R R

equal bandwidth share

Connection 1 throughput Connection 2 throughput

congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2 TCP connection 1 bottleneck router capacity R TCP connection 2

17

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Fairness (more)

Fairness and UDP

Multimedia apps often

do not use TCP

do not want rate

throttled by congestion control Instead use UDP:

pump audio/video at

constant rate, tolerate packet loss Research area: TCP

friendly Fairness and parallel TCP connections

nothing prevents app from

• pening parallel

connections between 2 hosts.

Web browsers do this Example: link of rate R

supporting 9 connections;

new app asks for 1 TCP, gets

rate R/10

another new app asks for 10

TCPs, gets R/2 !

16/4-07 Datakommunikation - Jonny Pettersson, UmU

A trip to Nevada

Tahoe

AIMD and Slow Start

Reno

Tahoe + Fast Retransmit + Fast Recovery

Vegas

”congestion avoidance” basic idea

• detect congestion in routers before packet loss
• lower the rate linearly

16/4-07 Datakommunikation - Jonny Pettersson, UmU

Chapter 3: Summary

principles behind

transport layer services:

multiplexing/demultiplexing reliable data transfer flow control congestion control

instantiation and

implementation in the Internet

UDP TCP

Next:

leaving the network

“edge” (application transport layer)

into the network “core”