TCP Kongestion Kontrol

5/20/2018 TCP Kongestion Kontrol

1/35

TCP Congestion Control


2/35

Internet Congestion Collapse Akhir tahun 80-an, Internet sering kolaps

akibat kongesti

Host

Host

Host

Congestion!Packet drops!!

Data + Retransmissions

More Drops!!!

Collapse


3/35

TCP congestion control

penting Algoritma kendali kongesti TCP

merupakan latar belakang utama

sukesnya Internet dalam menghadapi polaakses user yang tidak dapat diprediksi

(unpredictable user access patterns) serta

keterbatasan resource

Tanpa kendali kongesti TCP, Internet

sudah menjadi sejarah masa lalu

Mekanisme ini diterapkan di pengirim


4/35

Resource Management Solutions

Cara menangani kongesti resource allocation

How to effectively and fairly allocate resources among competingusers?

resources = bandwidth of links + buffers on the routers

control congestion if (and when) is occurs How to react when queues overflow and packets have to be

dropped?

Dua tempat implementasi penanganan kongesti routers di dalam jaringan (queuing discipline) hosts at the edges of the network (transport protocol)


5/35

The Cost of Congestion

Cost

High delay

Packet loss Wasted upstream

bandwidth when a pkt isdiscarded at downstream

Wasted bandwidth dueto retransmission (a pktgoes through a linkmultiple times)

Load

Load

Delay

Thr

oughput

knee cliff

congestion

collapse

packet

loss


6/35

Congestion Control vs.Congestion Avoidance

Congestion control goal

Stay left of cliff

Congestion avoidance goal

Stay left of knee

Load

Throughput

knee cliff

congestioncollapse


7/35

Detecting Congestion Packet dropsyang sering timbul

mengindikasikan kongesti

Src Dst

Packet

Ack

Drop

Timeout! No Ack= Congestion!


8/35

Mengendalikan kongesti Ukuran window dikurangijumlah paket

di jaringan lebih sedikit

Memperbesar ukuran window akan

lebih banyak paket di jaringan

Konsep congestion window:

Ukuran window lebih kecil jika kongestiterjadi dan membesar bila kongestiberkurang


9/35

Karakteristik skema congestion

avoidance yang diinginkan Efficiency (high utilization)

Fairness (resource sharing)

Distributedness (no central knowledge forscalability)

Convergence and stability (fast convergence

after disturbance, low oscillation) responsiveness (speed to new state, lower or

higher)

smoothness


10/35

AIMD

Additive Increase/Multiplicative Decrease

Setiap terjadi packet drop,CongestionWindow (cwnd) dibagi 2

(multiplicative decrease) Multiplicative decreasediperlukan untuk

mencegah kongesti

Jika tidak terjadi packet drop, cwnddiperbesar secara bertahap /gradually(additive increase)


11/35

Multiplicative Decrease cwnd dinyatakan dalam bytes, tetapi

literatur kebanyakan membicarakan

kongesti dalam istilah paket (yaitudalam MSS == Maximum SegmentSize)

Ukuran cwnd tidak boleh di bawahukuran sebuah paket


12/35

Additive IncreaseAdditive Increase merupakan reaksi

atas persepsi terhadap kapasitas yang

ada Ide dasar Linear Increase :

Untuk setiap paket yang dapat dikirim,

dinaikkan 1 packet cwnd dinaikkan 1 untuk setiap ACK yang

diterima


13/35

AIMD (cont)

In practice: increment a little for each ACKIncrement = (MSS*MSS)/cwnd

cwnd = cwnd + Increment

Source Destination

Algorithm

cwnd dinaikkan satu (satu paket) per

RTT (linear increase) cwnd dibagi dua jika suatu timeout

terjadi (multiplicative decrease)


14/35

AIMD (cont) Trace: sawtooth behavior

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


15/35

Problems Berapa ukuran window yang seharusnya?

Initially?

Bila terjadi packet lossdan timeout? Pessimistic window size? (mis. 1)

Additive increaseterlalu lambatkoneksi yangpendek tidak akan menggunakan bandwidth yang

ada secara penuh

Optimistic window size?

Pengiriman paket initialyang terlalu besar dapatmenyebabkan overflow di antrian router


16/35

Slow Start

Objective: menentukan kapasitas yang ada diawal dengan cepat

Idea Dimulai dengan CongestionWindow = 1 paket

CongestionWindow ditambah 1 untuk setiap ACK

Digunakan dalam dua kondisi Pada awal koneksi

Jika koneksi terputus ketika menunggu sebuahtimeout


17/35

Contoh Slow Start

segment1

ACKforsegment1

cwnd = 1

cwnd = 2 segment2

segment3

ACKforsegments2

cwnd = 4 segment4

segment5

segment6

ACKforsegments4

cwnd = 7

ACKforsegments3

ACKforsegments5

ACKforsegments6


18/35

Ukuran CongestionWindownaik dengancepat

Untuk setiap ACK, CongestionWindowselalu dinaikkan 1 tanpa peduli jumlahsegmen yang telah di-ACK

TCP melambatkan kenaikkkanCongestionWindowdengan kombinasislow start dengan AIMD

Sifat slow start


19/35

Slow Start dan AIMD Perubahan dari slow startke AIMD

Jika transmisi terputus, TCP mengetahui current

valuedari CongestionWindow (= value sebelumloss/2)

Menggunakan current value di atas sebagaitarget window size (= CongestionThreshold)

Slow start digunakan sampai tercapainyaCongestionThreshold, lalu digunakan additiveincrease (AIMD)


20/35

Fast Retransmit Masalah: TCP timeouts

menyebabkan periode idle

Fast retransmit: Ack dikirimkan untuk setiap

paket yang diterima

Duplikat dari ack sebelumnyadikirimkan jika paket yangditerima tidak terurut

Duplikasi ACKs digunakanjuga untuk mendorongretransmisi Ketika menerima 3 ACK yang

sama, sender akan me-retransmits paket yanghilang

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


21/35

Fast Recovery

Fast recovery mencegah slowstart setelah fast retransmit

Setelah 3 ACKs yang sama(duplikasi) diterima: Retransmit lost packet Congestion threshold

sshtresh= cwnd/2 cwnd = cwnd+3 Enter congestion avoidance Increment cwnd by one for

each additional duplicate ACK When ACK yang datang

meng-acknowledges databaru (digambar:AckNo=2028), set:

cwnd=ssthresh

enter congestion avoidance

1K SeqNo=0

AckNo=1024

AckNo=1024

1K SeqNo=1024

SeqNo=20481K

AckNo=1024

SeqNo=30721K

SeqNo=10241K

SeqNo=40961K

AckNo=2048

cwnd=12

sshtresh=5

cwnd=12

sshtresh=5

cwnd=12

sshtresh=5

cwnd=12

sshtresh=5

cwnd=9

sshtresh=9


22/35

Congestionwindow

10

5

15

20

0

Round-trip times

Slowstart

Congestionavoidance

Congestion occurs

Threshold

TCP Congestion Control


23/35

Self Clocking and Slow Start Setiap pengiriman paket di-clock oleh

sebuah ACKno bursts develop

W=1 W=2 W=4 W=5 W=6 W=7

Slow Start


24/35

Self Clocking in Operation Setiap pengiriman paket di-clock oleh

sebuah ACKno bursts develop

W=32


25/35

Self Clocking Interrupted Selama timeouts, ACKs tidak muncul (drained). Self clocking

terputus. Pengiriman berikutnya berupa pengiriman burstburst. Slow start kembali digunakan!

W=32

Lost

Timeout

Retransmission

Ack32

16 packet burst

Cut window in 1/2

ACKsDrained!!


26/35

Self Clocking and Fast

Retransmit / Fast Recovery Ketika fast retransmitdigunakan, paket di-

retransmisi sebelum semua ACKs hilang sehinggaslow starttidak diperlukan

W=32

Lost

FastRetransmission

Cut window in 1/2


27/35

Versi TCP TCP/Tahoe

TCP/Reno: banyak Operating System

menerapkan TCP/Reno type congestioncontrol

TCP/Vegas: not currently used


28/35

TCP Tahoe Dirancang oleh by Van Jacobson

Terdiri dari : basic TCP algorithms,

AIMD, Slow Start, Fast Retransmit


29/35

TCP Reno Dirancang oleh Van Jacobson pada akhir 80-an

Masih bekerja dengan baik walaupun bandwidthInternet telah meningkat lebih dari 10.000 kali

Duplicate ACKs: Fast retransmit

Fast recovery

Fast Recovery avoids slow start

Timeout: Retransmit

Slow Start

TCP Reno improves upon TCP Tahoe when a single

packet is dropped in a round-trip time.


30/35

TCP Tahoe vs TCP Reno


31/35

TCP Tahoe


32/35

TCP Reno

CASS

Fast retransmission/fast recovery


33/35

TCP New Reno Jika terjadi kehilangan beberapa paket, Reno has problems

Partial ACK:

Muncul bila beberapa paket hilang

Partial ACK hanya meng-acknowledge beberapa paket pada awalfast recovery

Sender harus menunggu sampai timeout terjadi

New Reno:

Partial ACK does not take sender out of fast recovery

Partial ACK causes retransmission of the segment followingthe acknowledged segment

New Reno can deal with multiple lost segments without going toslow start


34/35

SACK

SACK = Selective acknowledgment

Issue: Reno and New Reno retransmit at most 1 lost packet

per round trip time Selective acknowledgments:The receiver can

acknowledge non-continuous blocks of data (SACK 0-1023,1024-2047)

Multiple blocks can be sent in a single segment

TCP SACK: Enters fast recovery upon 3 duplicate ACKs

Sender keeps track of SACKs and infers if segments are lost. Senderretransmits the next segment from the list of segments that aredeemed lost.


35/35

TCP Vegas Menerapkan congestion avoidance

TCP Kongestion Kontrol

Documents

Transcript of TCP Kongestion Kontrol