Perbedaan TCP TAHOE, RENO, SACK & VEGAS - April Fatmasari-Catatan Mom Blogger

Membuka kembali folder yang masih tersimpan dan menemukan sedikit rangkuman yang sudah rapi sebagai bagian tugas dari topik khusus. Topik khusus ketika pertemuan itu membahas tentang jaringan komputer dengan lebih spesifik lagi mengenai TCP. Rangkuman ini diambil dari berbagai sumber.

TCP adalah koneksi berorientasi end-to-end protokol yang mempunyai mekanisme untuk memastikan keandalan dengan meminta penerima mengakui segmen yang diterima. Jaringan yang ada  tidak sempurna dan sebagian kecil dari paket hilang dalam perjalanan, baik karena kesalahan jaringan atau karena kongesti (kemacetan) dalam jaringan dan router yang menjatuhkan paket yang dikarenakan buffer overflows. 

TCP mempunyai peran penting untuk bereaksi terhadap packet loss dan mengambil tindakan untuk mengurangi kongesti. TCP menjamin kehandalan dengan memulai timer setiap kali mengirimkan segmen. Jika tidak menerima acknowledgment dari penerima dalam interval 'time-out' maka TCP melakukan retransmits segmen.

TCP TAHOE

Tahoe mengacu pada algoritma kontrol kongesti TCP yang disarankan oleh Van Jacobson. TCP didasarkan pada prinsip ‘packet conservation’, yaitu jika koneksi berjalan pada kapasitas bandwidth yang tersedia maka paket tidak disuntikkan ke jaringan kecuali paket diambil keluar juga. TCP menerapkan prinsip ini dengan menggunakan acknowledgement untuk paket keluar karena acknowledgement berarti bahwa paket diambil dari jaringan oleh penerima. Hal ini dilakukan untuk menjaga congestion window CWD yang mencerminkan kapasitas jaringan. Hal-hal yang perlu diselesaikan untuk memastikan keseimbangan ini:

1)       Penentuan bandwidth yang tersedia.

2)       Memastikan keseimbangan yang dipertahankan.

3)       Bagaimana bereaksi terhadap kongesti.

Menurut Feipeng (2008) TCP Tahoe adalah algoritma yang paling sederhana dari TCP varian lainnya. TCP Tahoe didasarkan pada tiga algoritma kongesti kontrol, yaitu slow start (SS), congestion avoidance (CA) dan fast retransmit. Tahoe tidak menggunakan algoritma fast recovery. Pada fase congestion avoidance, Tahoe memperlakukan duplikat tiga ACK sama dengan time-out. Ketika duplikat tiga ACK diterima, Tahoe akan menggunakan fast retransmit, menurunkan nilai CongWin menjadi 1, dan mulai masuk ke fase slow start.

Menurut Jusak (2011) algoritma TCP Tahoe dapat diuraikan sebagai berikut:

1)        Pada saat pengirim menerima 3 ACK ataupun time-out maka nilai CongWin akan dinaikkan secara eksponensial jika berada di bawah nilai threshold dan dinaikkan secara linier apabila nilai di atas threshold.

2)        Namun, saat terjadi kongesti dalam jaringan TCP Tahoe akan menurunkan nilai CongWin menjadi 1 MSS dan berikutnya kecepatan akan naik secara eksponensial. Gambar 1 merupakan contoh algoritma TCP Tahoe. Pada awalnya menggunakan fase slow start dan nilai threshold diset 16, kemudian saat menerima 3 duplikasi ACK (mengalami kongesti), Tahoe menurunkan nilai CongWin menjadi 1 MSS dan kemudian naik secara eksponensial dan begitu seterusnya.

Gambar 1. Algoritma TCP Tahoe

Ø  Slow Start:

Transmisi paket TCP diambil dari acknowledgement yang masuk. Setiap kali koneksi TCP dimulai atau restart setelah packet loss harus melalui prosedur yang disebut 'slow-start'. Alasan untuk prosedur ini adalah bahwa ledakan awal mungkin membanjiri jaringan dan koneksi tidak akan pernah dimulai. Slow-start menunjukkan bahwa pengirim mengatur congestion window untuk 1 dan kemudian untuk setiap ACK menerimanya meningkatkan CWD dengan 1, sehingga dalam waktu perjalanan pertama putaran (RTT) TCP mengirim 1 paket, di kedua TCP mengirim 2 dan ketiga TCP mengirim 4. Peningkatan terjadi secara eksponensial sampai TCP kehilangan paket yang merupakan tanda kongesti. Ketika TCP menghadapi kongesti, TCP menurunkan tingkat pengiriman dan mengurangi congestion window menjadi 1 kemudian mulai dari awal lagi. Tahoe mendeteksi packet loss dengan timeout.

Ø  Congestion Avoidance:

Untuk menghindari kemacetan Tahoe menggunakan ‘Additive Increase Multiplicative Decrease’. Sebuah packet loss diambil sebagai tanda kongesti dan Tahoe menyimpan setengah dari window saat ini sebagai ambang batas nilai. Kemudian set CWD ke 1 dan mulai slow-start sampai mencapai nilai ambang batas. CWD mengalami kenaikan linier sampai bertemu dengan sebuah packet loss. Window perlahan akan meningkat ketika mendekati kapasitas bandwidth.

Ø  Masalah:

Tahoe mengambil interval timeout secara lengkap untuk mendeteksi packet loss dan pada kenyataannya, di sebagian besar implementasi dibutuhkan lebih lama karena timeout. Juga karena tidak mengirim ACK yang langsung, ia akan mengirimkan acknowledgement kumulatif. Jadi, setiap kali sebuah paket hilang, TCP harus menunggu timeout dan pipeline dikosongkan. Hal ini membutuhkan bandwidth yang tinggi.

TCP RENO

Reno mempertahankan prinsip dasar Tahoe, seperti slow-start dan pengiriman kembali timer. Perbedaannya terdapat pada penambahan beberapa intelijen sehingga paket yang hilang terdeteksi sebelumnya dan pipaline tidak dikosongkan setiap kali paket hilang.

Menurut Feipeng (2008), TCP Reno berasal dari empat buah algoritma yaitu slow start (SS), congestion avoidance (CA), fast retransmit dan fast recovery.

Menurut Jusak (2011), TCP Reno membuang fase slow start pada saat mendeteksi kongesti melalui diterimanya 3 duplikasi ACK. Untuk selanjutnya proses ini disebut dengan nama Fast Recovery. Pada saat pengirim menerima 3 duplikasi ACK maka nilai threshold akan diturunkan menjadi setengah dari nilai CongWin saat sebelum terjadi kongesti, dan nilai CongWin ditetapkan sama dengan nilai threshold dan selanjutnya kecepatan pengiriman data akan meningkat secara linier. Algoritma TCP Reno dapat diuraikan sebagai berikut:

1)       Pada saat pengirim menerima 3 ACK ataupun time-out maka nilai CongWin akan dinaikkan secara eksponensial jika berada di bawah nilai threshold dan dinaikkan secara linier apabila nilai di atas threshold.

2)       Namun, saat terjadi kongesti dalam jaringan TCP Tahoe akan menurunkan nilai CongWin setengah dari nilai threshold sebelumnya dan berikutnya kecepatan akan naik secara linier.

Gambar 2. Algoritma TCP Reno

Gambar 2 merupakan contoh algoritma TCP Reno. Pada awalnya menggunakan fase slow start dan nilai threshold diset 16, kemudian saat menerima 3 duplikasi ACK, Reno menurunkan nilai CongWin menjadi setengah dari nilai threshold menjadi 8 MSS yang kemudian 8 akan ditetapkan menjadi nilai threshold selanjutnya dan kemudian naik secara eksponensial dan begitu seterusnya.

Ø  Masalah:

TCP Reno tampil sangat baik selama packet loss yang terjadi kecil. RENO tidak tampil terlalu baik dan kinerjanya hampir sama dengan Tahoe dalam kondisi packet loss yang tinggi. RENO hanya bisa mendeteksi packet loss tunggal. Jika ada packet drop beberapa maka informasi pertama tentang packet loss datang ketika TCP menerima ACK duplikat. Informasi tentang paket kedua yang hilang akan datang hanya setelah ACK untuk segmen pertama retransmitted mencapai pengirim setelah satu RTT.

TCP SACK

TCP SACK (Selective Acknowledgments) merupakan perpanjangan dari TCP Reno yang mendeteksi beberapa paket yang hilang, dan re-transmisi lebih dari satu paket yang hilang per RTT.

SACK mempertahankan bagian slow-start dan fastretransmit dari Reno, timeout dari Tahoe, membungkus paket hilang yang tidak terdeteksi oleh algoritma yang dimodifikasi.

Menurut Mathias, Mahdavi, Floyd, & Romanow (1996), Selective Acknowledgement (SACK) adalah strategi yang mengoreksi dalam menghadapi kehilangan beberapa segmen. Dengan selective acknowledgment, penerima data dapat menginformasikan pengirim tentang semua segmen yang telah berhasil tiba,sehingga pengirim perlu mengirim ulang hanya segmen yang benar-benar telah hilang. Pada metode pengiriman dengan menggunakan Selective Repeat terdapat kelemahan yaitu saat terdapat suatu paket data yang hilang, maka paket-paket data selanjutnya harus dikirimkan ulang lagi oleh karena itu dikenalah sebuah metode yang bernama Selective Acknowledgment (SACK).

Menurut Stretch (2010), SACK bekerja dengan cara menduplikasi paket acknowledgment yang mengandung urutan data yang telah diterima dan SACK yang memberitahukan bahwa telah berhasil menerima data yang lainnya. Dalam kata lain, Client mengatakan “Saya hanya menerima paket #1 saat pengiriman, tetapi saya juga telah menerima paket #3 dan #4”. Dengan demikian server dapat mengkirimkan ulang hanya paket yang gagal terkirim ke client.

Berikut ini merupakan contoh diagram transaksi pesan dengan menggunakan SACK. 

Gambar 3. Contoh diagram transaksi pesan SACK

ü  Poin 1

Pengiriman segmen#2 terjadi kegagalan/kehilangan.

ü  Poin 2

Client memberitahukan bahwa terdapat segmen yang hilang diantara segmen #1 dan #3 dengan cara mengirimkan duplikasi acknowledgment untuk segmen #1dan menambahkan sebuah SACK yang menandakan bahwa dia telah menerima segmen #3.

ü  Poin 3

Client menerima segmen #4 dan mengirimkan duplikasi acknowledgment yang lain untuk segmen #1, tetapi kali ini client manambahkan SACK yang menunjukkan bahwa client telah menerima segmen #3 dan #4.

ü  Poin 4

Server menerima duplikasi ACK dari client untuk segmen #1 dan SACK untuk segmen #3(yang keduanya terdapat pada paket TCP yang sama). Dari sini server dapat menduga bahwa client telah kehilangan segmen #2, yang kemudian akan dikirimkan ulang segmen #2. SACK yang berikutnya diterima oleh server merupakan pemberitahu bahwa client juga telah berhasil menerima segmen #4, jadi telah tidak ada lagi segmen yang harus dikirimkan.

ü  Poin 5

Client menerima segmen #2 dan mengirimkan sebuah ACK yang memberitahukan bahwa dia telah menerima seluruh data termasuk segmen #4.

Ø  Masalah:

Masalah terbesar dengan SACK adalah bahwa acknowledgment yang dapat dipilih saat ini tidak disediakan oleh penerima. Untuk menerapkan SACK perlu mengimplementasikan selective acknowledgment yang merupakan tugas yang tidak mudah.

TCP VEGAS

TCP Vegas adalah sebuah kontrol kemacetan TCP atau dengan kata lain untuk menghindari kemacetan jaringan, algoritma yang menekankan keterlambatan paket, dari pada kehilangan paket, sebagai tanda untuk membantu menentukan kadar saat paket akan dikirim. TCP Vegas merupakan pengembangan dari TCP Reno. TCP Vegas dikembangkan di University of Arizona oleh Lawrence Brakmo dan Larry L. Peterson.

Perbedaan antara TCP Vegas dengan  TCP lainnya terletak pada fase  slowstart, pendeteksian bandwidh yang tersedia, serta mekanisme pendeteksian paket yang hilang. Pada TCP Reno  CWND (congestion window) akan terus bertambah sampai terdeteksi adanya packet loss yang diakibatkan oleh congestion. Jika packet loss yang diakibatkan oleh kongesti terjadi, nilai  CWND akan diperkecil menjadi  CWND/2, yang mengakibatkan penurunan throughput. Penambahan  CWND tidak dapat dihindari dikarenakan mekanisme  congestion control pada TCP Reno hanya dapat mendeteksi packet loss jika terjadi kongesti. Jadi jika ada packet loss yang bukan disebabkan oleh kongesti, maka  CWND akan terus bertambah sehingga ukuran  CWND tidak dapat terkontrol dengan tepat yang dapat mengakibatkan terjadinya packet loss semakin banyak.

Ide dasar dari TCP Vegas adalah mencegah terjadinya  packet loss yang bukan hanya disebabkan oleh kongesti sehingga ukuran  CWND menjadi tidak terlalu besar. Dengan terkontrolnya ukuran  CWND dengan tepat, maka paket yang hilang dalam jaringan dapat dicegah, sehingga penurunan  throughput akibat dari mengecilnya ukuran  CWND dapat dihindar. TCP Vegas menggunakan mekanisme lain untuk mendeteksi kongesti. TCP Vegas mengatur  CWND dengan mengamati perubahan RTT (Round Trip Time) dari paket yang dikirimkan sebelumnya oleh pengirim kepada penerima.

Pada TCP Vegas dalam mengamati keadaan  jaringan, tidak hanya berdasarkan umpan balik ACK, tapi juga mengestimasi   kondisi jaringan berdasarkan RTT (round trip time). Vegas mengontrol mengamati ukuran CWND dengan mengamati RTT dari paket yang dikirim sebelumnya oleh pengirim. Jika RTT besar, maka jaringan mengalami kongesi dan memperkecil ukuran  CWND. Jika RTT kecil berarti jaringan dalam keadaan normal dan ukuran CWND diperbesar.

Kesimpulan:

Dengan demikian jelaslah bahwa TCP Vegas jelas lebih baik daripada

1)       Tahoe:

•      Penyebabnya adalah Vegas jauh lebih kuat dalam menghadapi paket yang hilang. Vegas bisa mendeteksi dan mengirimkan kembali paket yang hilang lebih cepat daripada timeout di Tahoe.

•      Vegas lebih sedikit melakukan re-transmisi karena pipeline tidak dikosongkan secara keseluruhan setiap kali kehilangan paket.

•      Vegas lebih baik dalam menghindari kongesti. Congestion avoidance dan algoritma slow-start yang dimodifikasi sangat akurat mengukur bandwidth yang tersedia yang tersedia. Oleh karena itu vegas menggunakan sumber daya jaringan secara efisien dan tidak memberikan kontribusi terhadap kongesti.

2)       Reno:

•      Lebih dari setengah timeout Reno dicegah oleh Vegas karena Vegas mendeteksi dan re-transmit lebih dari satu paket hilang sebelum timeout terjadi.

•      Vegas tidak harus menunggu selama 3 paket terduplikat sehingga paket dapat ditransmit  kembali lebih cepat.

•      Vegas tidak mengurangi congestion window terlalu prematur.

•      Keuntungannya dalam mencegah kongesti dan pemanfaatan bandwidth lebih dari Tahoe ada di sini juga.

3)       SACK:

TCP Vegas tidak memiliki keuntungan yang jelas dibandingkan dengan TCP SACK. Satu-satunya bidang yang mengungguli SACK adalah:

•      Estimation incipient congestion dan estimasi kongesti yang efisien dengan mengukur perubahan dalam throughput daripada packet loss. Hal ini menyebabkan pemanfaatan bandwidth lebih baik dan kongesti lebih rendah.

·       Performa Vegas lebih stabil daripada SACK. SACK menggunakan packet loss  untuk menunjukkan kongesti sehingga pengirim meningkatkan tingkat pengiriman paket secara terus menerus sampai ada kongesti dan kemudian kembali ke awal lagi. Siklus ini terus berlanjut dan sistem terus berosilasi. TCP Vegas meratakan laju pengiriman pada titik penggunaan bandwidth yang optimal sehingga lebih stabil.

•      Keuntungan lain dari TCP Vegas atau lebih tepatnya merugikan SACK adalah tidak mudah menggabungkan TCP SACK dengan TCP yang ada saat ini.