11
Upcoming SlideShare
Loading in...5
×
 

11

on

  • 381 views

 

Statistics

Views

Total Views
381
Views on SlideShare
381
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

11 11 Presentation Transcript

  • TCP Congestion Control
  • Internet Congestion Collapse  Akhir tahun 80-an, Internet sering kolaps akibat kongesti Data + RetransmissionsHost Congestion! Packet drops!!Host CollapseHost More Drops!!!
  • TCP congestion control penting Algoritma kendali kongesti TCP merupakan latar belakang utama sukesnya Internet dalam menghadapi pola akses user yang tidak dapat diprediksi (unpredictable user access patterns) serta keterbatasan resource Tanpa kendali kongesti TCP, Internet sudah menjadi sejarah
  • Resource Management Solutions Cara menangani kongesti  resource allocation  How to effectively and fairly allocate resources among competing users?  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)
  • The Cost of Congestion packet knee cliffCost loss Throughput High delay Packet loss congestion collapse Wasted upstream bandwidth when a pkt is discarded at Load downstream Delay Wasted bandwidth due to retransmission (a pkt goes through a link multiple times) Load
  • Congestion Control vs. Congestion Avoidance Congestion control goal  Stay left of cliff Congestion avoidance goal  Stay left of knee knee cliff Throughput congestion collapse Load
  • Detecting Congestion  Packet drops yang sering timbul mengindikasikan kongesti PacketSrc Dst Drop Ack Timeout! No Ack = Congestion!
  • Mengendalikan kongesti Ukuran window dikurangi jumlah paket di jaringan lebih sedikit Memperbesar ukuran window  akan lebih banyak paket di jaringan Konsep congestion window :  Ukuran window lebih kecil jika kongesti terjadi dan membesar bila kongesti berkurang
  • Karakteristik skema congestion avoidance yang diinginkan Efficiency (high utilization) Fairness (resource sharing) Distributedness (no central knowledge for scalability) Convergence and stability (fast convergence after disturbance, low oscillation)  responsiveness (speed to new state, lower or higher)  smoothness
  • AIMDAdditive Increase/MultiplicativeDecrease Setiap terjadi packet drop, CongestionWindow (cwnd) dibagi 2 (multiplicative decrease)  Multiplicative decrease diperlukan untuk mencegah kongesti Jika tidak terjadi packet drop, cwnd diperbesar secara bertahap /gradually (additive increase)
  • Multiplicative Decrease cwnd dinyatakan dalam bytes, tetapi literatur kebanyakan membicarakan kongesti dalam istilah paket (yaitu dalam MSS == Maximum Segment Size) Ukuran cwnd tidak boleh di bawah ukuran sebuah paket
  • Additive Increase Additive 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
  • AIMD (cont) Source Destination Algorithm  cwnd dinaikkan satu (satu paket) per RTT (linear increase)  cwnd dibagi dua jika suatu timeout terjadi (multiplicative decrease) … In practice: increment a little for each ACK Increment = (MSS*MSS)/cwnd cwnd = cwnd + Increment
  • AIMD (cont)  Trace: sawtooth behavior 70 60 50 40KB 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 Time (seconds)
  • Problems Berapa ukuran window yang seharusnya?  Initially?  Bila terjadi packet loss dan timeout? Pessimistic window size? (mis. 1)  Additive increase terlalu lambat – koneksi yang pendek tidak akan menggunakan bandwidth yang ada secara penuh Optimistic window size?  Pengiriman paket initial yang terlalu besar dapat menyebabkan overflow di antrian router
  • Slow Start Objective: menentukan kapasitas yang ada di awal 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 sebuah timeout
  • Contoh Slow Start cwnd = 1 segment 1 ent 1 ACK for segm cwnd = 2 segment 2 segment 3 ents 2 ACK for segm ents 3 ACK for segm cwnd = 4 segment 4 segment 5 segment 6 ents 4 ACK for segm ents 5 ACK for segm ents 6 ACK for segm cwnd = 7
  • Sifat slow start Ukuran CongestionWindow naik dengan cepat  Untuk setiap ACK, CongestionWindow selalu dinaikkan 1 tanpa peduli jumlah segmen yang telah di-ACK TCP melambatkan kenaikkkan CongestionWindow dengan kombinasi slow start dengan AIMD
  • Slow Start dan AIMD Perubahan dari slow start ke AIMD  Jika transmisi terputus, TCP mengetahui current value dari CongestionWindow (= value sebelum loss/2)  Menggunakan current value di atas sebagai “target” window size (= CongestionThreshold)  Slow start digunakan sampai tercapainya CongestionThreshold, lalu digunakan additive increase (AIMD)
  • Fast Retransmit Sender Receiver Packet 1 Masalah: TCP timeouts Packet 2 ACK 1 menyebabkan periode idle Packet 3 Packet 4 ACK 2 Fast retransmit: ACK 2 Packet 5  Ack dikirimkan untuk setiap Packet 6 paket yang diterima ACK 2  Duplikat dari ack sebelumnya ACK 2 dikirimkan jika paket yang Retransmit diterima tidak terurut packet 3  Duplikasi ACKs digunakan ACK 6 juga untuk mendorong retransmisi  Ketika menerima 3 ACK yang sama, sender akan me-retransmits paket yang hilang
  • Fast Recovery Fast recovery mencegah slow start 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 “data baru” (digambar: AckNo=2028), set: cwnd=ssthresh enter congestion avoidance
  • TCP Congestion Control Congestion Congestion occurs 20 avoidance 15Congestion window Threshold 10 Slow start 5 0 Round-trip times
  • Self Clocking and Slow Start  Setiap pengiriman paket di- “clock” oleh sebuah ACK – no bursts develop …W=1 W=2 W=4 W=5 W=6 W=7 Slow Start
  • Self Clocking in Operation  Setiap pengiriman paket di-“clock” oleh sebuah ACK – no bursts develop… … W=32
  • Self Clocking Interrupted Selama timeouts, ACKs tidak muncul (drained). Self clocking terputus. Pengiriman berikutnya berupa pengiriman burst burst. Slow start kembali digunakan! ACKs Lost Drained!! Ack32… … 16 packet burst W=32 Retransmission Timeout Cut window in 1/2
  • Self Clocking and Fast Retransmit / Fast Recovery Ketika fast retransmit digunakan, paket di- retransmisi sebelum semua ACKs hilang sehingga slow start tidak diperlukan Lost… … Fast Retransmission W=32 Cut window in 1/2
  • Versi TCP TCP/Tahoe TCP/Reno: banyak Operating System menerapkan TCP/Reno type congestion control TCP/Vegas: not currently used
  • TCP Tahoe Dirancang oleh by Van Jacobson Terdiri dari : basic TCP algorithms, AIMD, Slow Start, Fast Retransmit
  • TCP Reno Dirancang oleh Van Jacobson pada akhir 80-an Masih bekerja dengan baik walaupun bandwidth Internet 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.
  • TCP Tahoe vs TCP Reno
  • TCP Tahoe
  • TCP Reno SS CA Fast retransmission/fast recovery
  • 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 awal fast 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 following the acknowledged segment New Reno can deal with multiple lost segments without going to slow start
  • 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. Sender retransmits the next segment from the list of segments that are deemed lost.
  • TCP Vegas Menerapkan congestion avoidance