Wawancara Jaringan: Bagaimana Cara TCP Mendeteksi dan Memulihkan Diri dari Kehilangan Paket?

Prompt dan cakupan

Pengirim mentransmisikan lima segmen data TCP berukuran 1.000 bita secara berurutan mulai dari nomor urut 1.000. Segmen kedua hilang dan tiga segmen berikutnya sampai di penerima. Turunkan urutan ACK, SACK, dan transmisi ulang, lalu bandingkan batasan timeout, fast retransmit, serta deteksi kehilangan modern.

Asumsikan koneksi telah terbentuk, kelima segmen membawa data, receive window dan congestion window mengizinkan kelimanya berada dalam status in-flight, penerima dapat menyangga (buffer) data yang tidak berurutan, dan SACK telah dinegosiasikan selama handshake. Nomor urut menghitung bita, dan rentang di bawah ini bersifat setengah-terbuka (half-open). Tanpa SACK, penalaran ACK kumulatif dan fast-retransmit klasik tetap berlaku; pengirim hanya kehilangan informasi tentang bita dengan nomor urut lebih tinggi mana yang telah tiba.

Pertanyaan ini cocok untuk peran backend, infrastruktur, SRE, klien, jaringan, dan rekayasa perangkat lunak umum. Kompetensi intinya adalah menurunkan dan memvalidasi status protokol transport, sehingga kategorinya adalah general. Pertanyaan ini tidak menanyakan tentang isolasi lintas-stream HTTP/3 atau pembentukan, pemutusan, dan TIME_WAIT pada TCP.

Apa yang dievaluasi pewawancara

Pertama, apakah kandidat dapat menyebutkan satuannya dengan benar? TCP memberi nomor pada bita. Nomor urut suatu segmen mengidentifikasi bita data pertamanya, dan ACK kumulatif menyebutkan bita berikutnya yang diharapkan penerima; ini bukan penghitung paket.

Kedua, apakah kandidat dapat menurunkan garis waktu? Begitu segmen kedua hilang, segmen berikutnya yang datang tidak berurutan tidak memajukan ACK kumulatif, tetapi memicu ACK duplikat. ACK duplikat ketiga adalah sinyal fast-retransmit klasik menurut RFC 5681. Menghitung ACK yang pertama kali mengonfirmasi segmen A sebagai duplikat akan menghasilkan jawaban yang salah hitung satu angka (off-by-one).

Ketiga, apakah kandidat dapat memisahkan mekanisme pemulihan? RTO menangani kehilangan yang tidak menghasilkan cukup umpan balik ACK. Fast retransmit menggunakan ACK duplikat yang dihasilkan oleh data berikutnya untuk memulihkan transmisi lebih cepat. SACK mendeskripsikan blok bita tidak berurutan yang diterima sehingga pengirim dapat menghindari pengiriman ulang data yang telah sampai, tetapi SACK tidak menggantikan ACK kumulatif maupun mengontrol congestion window secara independen.

Keempat, apakah kandidat dapat menjelaskan ketidakpastian? Pengurutan ulang paket (reordering) atau replikasi juga dapat menghasilkan ACK duplikat, dan lonjakan RTT dapat menyebabkan timeout tanpa kehilangan nyata. Pengiriman yang andal, deteksi kehilangan, dan kontrol kongesti saling berinteraksi, tetapi merupakan konsep yang berbeda.

Kelima, apakah jawabannya dapat melampaui slogan buku teks? Kandidat yang kuat menjelaskan mengapa flight yang kecil atau tail loss mungkin tidak menghasilkan tiga ACK duplikat dan mencatat bahwa implementasi dapat menggunakan RACK-TLP untuk mengurangi ketergantungan pada ambang batas jumlah paket tetap dan RTO dengan menggabungkan waktu transmisi dengan umpan balik SACK.

Pertanyaan klarifikasi

• Apakah nomor urut dan panjang dinyatakan dalam bita? Ubah label paket relatif menjadi rentang bita terlebih dahulu. SYN dan FIN juga mengonsumsi ruang urutan, tetapi masalah ini hanya memuat data pada koneksi yang sudah terbentuk.
• Apakah SACK dinegosiasikan selama handshake? Tanpanya, pemulihan bergantung pada ACK kumulatif dan algoritma yang dipilih pengirim. Dengannya, ACK duplikat dapat membawa blok data tidak berurutan yang telah diterima.
• Apakah flight cukup besar untuk menghasilkan tiga ACK duplikat? Setidaknya tiga segmen baru setelah celah kehilangan harus tiba untuk memberikan sinyal klasik tersebut. Segmen ekor (tail) yang hilang biasanya tidak memiliki data setelahnya untuk membuat ACK tersebut.
• Apakah kita menjelaskan RFC 5681 atau satu kernel konkret? Ambang batas klasik berguna untuk penurunan konsep. Stack nyata mungkin menggunakan ambang batas yang dapat dikonfigurasi, pemulihan SACK, RACK-TLP, atau ekstensi lain, sehingga kesimpulan packet-trace memerlukan informasi sistem operasi dan versinya.
• Apakah tujuannya kebenaran protokol atau diagnosis performa? Kebenaran menjelaskan pengiriman berurutan pada akhirnya. Diagnosis juga memerlukan RTT, RTO, status kongesti, reordering, titik tangkapan paket (capture points), dan perilaku offload NIC.

Kerangka jawaban 30 detik

"Nomor urut TCP menghitung bita, dan ACK kumulatif adalah bita berikutnya yang diharapkan. Segmen A mencakup 1.000 hingga 1.999, sehingga penerimaannya menghasilkan ACK 2.000. Segmen B, yang mencakup 2.000 hingga 2.999, hilang. Tiga segmen berikutnya dapat disangga, tetapi celah masih dimulai dari 2.000, sehingga masing-masing menghasilkan ACK 2.000 lainnya. Jika SACK dinegosiasikan, ACK tersebut juga melaporkan bita yang diterima dari 3.000 hingga 5.999.

Pada alur klasik RFC 5681, ACK duplikat ketiga memicu fast retransmission untuk bita 2.000 hingga 2.999 tanpa menunggu RTO. Setelah celah terisi, ACK kumulatif langsung maju ke 6.000. Jika flight terlalu kecil, ekor hilang, atau umpan balik ACK berhenti, pengirim mungkin memerlukan RTO. RTO diturunkan dari smoothed RTT dan variasi RTT, lalu diterapkan exponential backoff setelah timeout, disertai pengurangan congestion window yang lebih drastis. SACK meningkatkan presisi pemulihan untuk beberapa celah sekaligus. RACK-TLP modern juga dapat menggunakan waktu transmisi, umpan balik SACK, dan probe untuk mendeteksi kehilangan ekor atau transmisi ulang lebih cepat. Dalam trace, saya akan mengorelasikan ACK kumulatif, blok SACK, waktu transmisi ulang, dan stack TCP aktual daripada menganggap reordering atau label penganalisis sebagai bukti kehilangan mutlak."

Pembahasan mendalam langkah demi langkah

Langkah 1: Tentukan rentang bita dan ACK kumulatif

Kelima rentang bita logis adalah:

A: SEQ=1000, LEN=1000 -> [1000, 2000)  delivered
B: SEQ=2000, LEN=1000 -> [2000, 3000)  lost
C: SEQ=3000, LEN=1000 -> [3000, 4000)  delivered
D: SEQ=4000, LEN=1000 -> [4000, 5000)  delivered
E: SEQ=5000, LEN=1000 -> [5000, 6000)  delivered

Setelah A tiba, penerima menyimpan bita 1.000 hingga 1.999 secara berurutan, sehingga mengirimkan ACK=2000. ACK ini memajukan batas konfirmasi untuk pertama kalinya. Ini adalah ACK baru, bukan duplikat.

Setelah B hilang, C dapat diterima dalam receive window tetapi tidak dapat mengisi celah yang dimulai dari 2.000. Penerima dapat menyangga C, sementara konfirmasi kumulatifnya tetap ACK=2000. Hal yang sama berlaku untuk D dan E. RFC 9293 mendefinisikan bidang ACK sebagai nomor urut berikutnya yang diharapkan oleh peer penerima, itulah sebabnya bidang tersebut tidak melompat ke akhir setiap segmen yang tidak berurutan.

Langkah 2: Turunkan tiga ACK duplikat dan fast retransmit

Pada alur klasik RFC 5681, setiap kedatangan C, D, dan E menyebabkan ACK duplikat ACK=2000 dikirimkan secara langsung:

Receive A             -> ACK 2000                     new ACK
Receive C; B is absent -> ACK 2000 + SACK [3000,4000) duplicate ACK 1
Receive D; B is absent -> ACK 2000 + SACK [3000,5000) duplicate ACK 2
Receive E; B is absent -> ACK 2000 + SACK [3000,6000) duplicate ACK 3
Sender retransmits B   -> SEQ 2000, LEN 1000
Receiver gets B        -> ACK 6000                     gap closes

Ketika ACK duplikat ketiga mencapai pengirim, pengirim menyimpulkan bahwa B kemungkinan besar hilang dan melakukan transmisi ulang cepat (fast-retransmit) [2000,3000) alih-alih menunggu timer transmisi ulang. C, D, dan E sudah disangga. Ketika B tiba, rentang yang berurutan langsung mencakup hingga bita 5.999, sehingga ACK kumulatif dapat langsung berpindah dari 2.000 ke 6.000.

Tiga ACK duplikat adalah heuristik kehilangan, bukan bukti matematis mutlak. Reordering pada jaringan dapat menyebabkan data dengan nomor urut lebih tinggi sampai lebih dulu dan menghasilkan pola ACK yang sama. Segmen data atau ACK yang tereplikasi juga dapat menyebabkannya. Ambang batas ini menyeimbangkan perbaikan yang lebih cepat dengan risiko salah mengklasifikasikan reordering, dan stack aktual dapat menambahkan algoritma lain.

Langkah 3: Nyatakan apa yang ditambahkan SACK dan apa yang tidak

ACK kumulatif hanya menyatakan bahwa semua data di bawah 2.000 telah tiba secara berurutan. Opsi SACK dapat melaporkan tambahan blok tidak berurutan yang disimpan dalam penyangga penerima, seperti [3000,6000). Ini menutup celah informasi: pengirim tahu bahwa data dengan nomor urut lebih tinggi telah tiba dan dapat melewati blok-blok tersebut saat memperbaiki beberapa celah kehilangan.

SACK memiliki tiga batasan penting:

1. SACK-Permitted harus dinegosiasikan dalam pertukaran SYN sebelum penerima dapat menyertakan blok SACK dalam ACK berikutnya.
2. Blok SACK tidak memajukan ACK kumulatif dari 2.000 ke 6.000. Hanya pengisian [2000,3000) yang memajukan batas berurutan tersebut.
3. SACK adalah informasi penerima yang bersifat anjuran (advisory). Ini membantu pengirim memelihara papan skor (scoreboard) pemulihan; algoritma pengirim tetap menentukan urutan transmisi ulang dan respons kongesti.

Jika B dan D sama-sama hilang, satu fast retransmission awalnya hanya memperbaiki B. Pemulihan klasik tanpa SACK memiliki lebih sedikit informasi tentang apakah D telah sampai. SACK dapat melaporkan blok C dan E yang terpisah, memungkinkan pengirim mengidentifikasi kedua celah secara lebih presisi dan menghindari pengiriman ulang C dan E yang sudah disangga.

Langkah 4: Jelaskan mengapa RTO tetap diperlukan

Fast retransmit bergantung pada umpan balik ACK. Jika pengirim hanya mentransmisikan A dan B lalu kehilangan segmen ekor B, tidak ada C, D, atau E yang tiba untuk membuat ACK duplikat. Jika jalur ACK balik juga gagal, pengirim juga tidak dapat mengumpulkan tiga duplikat. Timer transmisi ulang adalah jaring pengaman terakhir.

RFC 6298 memelihara smoothed round-trip time SRTT, variasi round-trip RTTVAR, dan granularitas clock G:

For the first RTT sample R:
SRTT   = R
RTTVAR = R / 2
RTO    = SRTT + max(G, 4 * RTTVAR)

For a later sample R':
RTTVAR = (1 - 1/4) * RTTVAR + 1/4 * abs(SRTT - R')
SRTT   = (1 - 1/8) * SRTT   + 1/8 * R'
RTO    = SRTT + max(G, 4 * RTTVAR)

Sebagai contoh, dengan sampel pertama R=120 ms dan G tidak lebih besar dari 240 ms, SRTT=120 ms, RTTVAR=60 ms, dan rumus mentah menghasilkan 360 ms. RFC 6298 merekomendasikan pembulatan RTO di bawah satu detik menjadi satu detik, dan merekomendasikan RTO awal satu detik sebelum sampel RTT tersedia. Kernel nyata mungkin menggunakan algoritma dan detail implementasi yang lebih baru, sehingga interval yang tidak tepat satu detik tidak dengan sendirinya menggugurkan pemulihan timeout.

Ketika timer kedaluwarsa, pengirim mentransmisikan ulang data tertua yang belum dikonfirmasi dan menggandakan RTO sebelum memulai ulang timer. Exponential backoff mencegah penyuntikan data berulang kali ke jalur yang mengalami kongesti parah atau terputus. Mengukur RTT langsung dari segmen yang ditransmisikan ulang menimbulkan ambiguitas: apakah ACK tersebut mengonfirmasi segmen asli atau hasil transmisi ulang? Tanpa timestamp yang menyelesaikan ambiguitas itu, algoritma Karn mengecualikan sampel tersebut dari pembaruan RTT.

Langkah 5: Pisahkan pemulihan keandalan dari respons kongesti

Transmisi ulang menjawab "bagaimana kita mengganti bita yang hilang?" Kontrol kongesti menjawab "berapa banyak data yang boleh tetap in-flight setelahnya?" Sinyal kehilangan memengaruhi keduanya, tetapi kedua tugas tersebut berbeda.

RFC 5681 klasik memperlakukan RTO sebagai sinyal yang lebih kuat. ssthresh tidak lebih dari max(FlightSize/2, 2*SMSS), dan cwnd turun menjadi tidak lebih dari satu segmen ukuran penuh sebelum slow start dimulai kembali. Tiga ACK duplikat menunjukkan bahwa segmen berikutnya masih tiba dan clock ACK masih berjalan, sehingga pengirim memasuki fast retransmit dan fast recovery, mengurangi window tanpa menerapkan reset RTO yang sama.

Flow control adalah batasan terpisah lainnya. rwnd yang diiklankan penerima melindungi kapasitas penyangga penerima, sedangkan cwnd pengirim melindungi jaringan. Keduanya membatasi pengiriman aktual. SACK mendeskripsikan status penerimaan; ini tidak memperbesar rwnd maupun cwnd.

Langkah 6: Tambahkan batasan RACK-TLP modern

Aturan tiga ACK duplikat tetap bekerja buruk untuk flight pendek, kehilangan segmen ekor, transmisi ulang yang hilang, dan reordering yang signifikan. RFC 8985 merekomendasikan RACK-TLP sebagai alternatif untuk penghitungan ACK duplikat tradisional. RACK menggabungkan waktu transmisi terbaru setiap segmen, RTT, dan umpan balik SACK untuk menyimpulkan apakah transmisi sebelumnya hilang. TLP mengirimkan probe ketika umpan balik ACK minim di dekat ekor, berusaha memulihkan clock ACK sebelum RTO terjadi.

Jawaban wawancara harus terlebih dahulu menurunkan mekanisme klasik dan kemudian menyebutkan batasan implementasinya. Trace nyata mungkin menunjukkan pemulihan dengan kurang dari tiga ACK duplikat atau adanya tail probe. Periksa algoritma dan versi stack. Mengatakan bahwa setiap implementasi "menunggu tepat tiga duplikat atau selalu menunggu RTO" adalah kekeliruan yang menyamakan model pengajaran dengan perilaku mutakhir yang lengkap.

Langkah 7: Validasi dengan bukti paket, bukan sekadar hitungan transmisi ulang

Bangun garis waktu yang dapat direkonsiliasi di seluruh pengamatan:

1. Tangkap paket di pengirim dan penerima untuk menemukan di mana segmen asli hilang, alih-alih mengandalkan satu titik pengamatan saja.
2. Selaraskan SEQ, LEN, ACK kumulatif, dan blok SACK untuk membuktikan bahwa celah bita memang ada.
3. Hitung duplikat hanya setelah ACK baru sebelumnya; jangan hitung ACK baseline itu sendiri.
4. Bandingkan waktu transmisi ulang dengan ACK duplikat ketiga atau RTO yang diharapkan, lalu periksa status kongesti, RTT, dan algoritma pemulihan stack.
5. Korelasikan delay aplikasi dengan kehilangan antarmuka, reordering, dan sinyal antrean daripada menentukan akar masalah hanya dari satu label Wireshark.

Nilai tcp.analysis.fast_retransmission, tcp.analysis.retransmission, dan tcp.analysis.duplicate_ack pada Wireshark adalah inferensi penganalisis dari tangkapan yang tersedia, bukan flag yang dibawa dalam header TCP. TSO dan GRO juga dapat membuat batas segmen pada tangkapan host berbeda dari paket aktual di kabel jaringan. Kesimpulan penting memerlukan pemeriksaan silang dengan ruang urutan dan pewaktuan dari kedua titik akhir.

Contoh jawaban berkualitas tinggi

"Saya akan menurunkannya dalam ruang urutan bita. A memiliki SEQ=1000 dan panjang 1.000, sehingga setelah menerima A, penerima berikutnya mengharapkan bita 2.000 dan mengirimkan ACK 2.000 baru. B mencakup bita 2.000 hingga 2.999 dan hilang. C, D, dan E mencakup bita 3.000 hingga 5.999 dan tiba, tetapi tidak ada yang mengisi celah di 2.000. Oleh karena itu, ACK kumulatif tetap di 2.000. Setiap segmen yang tidak berurutan menghasilkan satu ACK duplikat. Jika SACK dinegosiasikan, penerima juga secara progresif melaporkan bahwa bita 3.000 hingga 5.999 telah disangga.

Di bawah perilaku klasik RFC 5681, C, D, dan E menghasilkan tiga ACK duplikat untuk 2.000. Yang ketiga memicu pengirim untuk melakukan fast-retransmit B tanpa menunggu RTO. Ketika B tiba, penyangga penerima menjadi berurutan dan ACK kumulatif melompat langsung ke 6.000. Kesalahan off-by-one yang umum adalah menghitung ACK 2.000 pertama setelah A sebagai duplikat; padahal itu adalah ACK baru yang memajukan batas.

Jika kehilangan terjadi di ekor atau flight terlalu kecil, tiga segmen berikutnya tidak ada, sehingga RTO adalah jaring pengaman terakhir. RTO diestimasi dari smoothed RTT ditambah empat kali variasi RTT, dan RFC 6298 menerapkan exponential backoff setelah timeout. RTO biasanya menyebabkan pengurangan congestion window yang lebih besar daripada fast recovery karena clock ACK mungkin telah berhenti. SACK memberi tahu pengirim bita lebih tinggi mana yang tidak berurutan yang telah tiba, yang sangat berguna untuk beberapa celah sekaligus. SACK tidak memajukan ACK kumulatif dengan sendirinya dan bukan merupakan algoritma kontrol kongesti.

Stack nyata juga dapat menggunakan RACK-TLP untuk menyimpulkan kehilangan dari waktu transmisi dan umpan balik SACK serta mem-probe kehilangan di ekor. Tiga ACK duplikat adalah penurunan klasik yang wajib dipahami, bukan satu-satunya pemicu dalam setiap trace. Dalam diagnosis, saya akan menyelaraskan nomor urut, panjang, ACK kumulatif, blok SACK, dan waktu transmisi ulang di kedua titik akhir, memeriksa stack dan pengaturan offload, lalu membedakan kehilangan nyata dari reordering, kehilangan jalur ACK, atau inferensi penganalisis."

Kesalahan umum

• Memperlakukan ACK sebagai nomor paket → TCP mengonfirmasi ruang bita yang berurutan → turunkan bita berikutnya yang diharapkan dengan SEQ + LEN.
• Menghitung ACK 2.000 setelah A sebagai duplikat ke-1 → ini memajukan batas kumulatif untuk pertama kalinya → mulai hitung ACK berikutnya dengan nomor yang sama yang tidak memajukannya.
• Mengklaim C menghasilkan ACK 4.000 → celah bita di B tetap ada → pertahankan ACK kumulatif di 2.000 dan laporkan C dengan SACK.
• Mengklaim SACK menggantikan ACK kumulatif → TCP tetap memajukan batas berurutan secara kumulatif → perlakukan SACK sebagai informasi blok tidak berurutan tambahan.
• Mengklaim tiga duplikat membuktikan kehilangan mutlak → reordering dan replikasi dapat menghasilkan sinyal yang sama → sebut ini sebagai heuristik kehilangan klasik dan verifikasi garis waktunya.
• Mengklaim setiap kehilangan pasti di-fast-retransmit → tail loss atau flight kecil mungkin tidak menghasilkan cukup ACK duplikat → pertahankan konsep RTO dan jelaskan peningkatan dari RACK-TLP.
• Menggabungkan transmisi ulang dan kontrol kongesti → memperbaiki data dan membatasi laju pengiriman menyelesaikan masalah yang berbeda → nyatakan tindakan pemulihan, cwnd, dan rwnd secara terpisah.
• Memperlakukan label Wireshark sebagai bit protokol di kabel → label disimpulkan dari konteks tangkapan dan dapat terdistorsi oleh offload → lakukan pemeriksaan silang pada ruang urutan dan pewaktuan di kedua titik akhir.

Pertanyaan lanjutan

Lanjutan 1: Jika hanya dua segmen yang dikirim dan yang kedua hilang, apakah fast retransmit terjadi?

Tidak pada alur klasik. Tidak ada data dengan nomor urut lebih tinggi yang mencapai penerima, sehingga penerima tidak dapat menghasilkan tiga ACK duplikat. Pengirim biasanya menunggu RTO. Stack RACK-TLP dapat mengirimkan tail-loss probe untuk meminta umpan balik, tetapi RTO tetap menjadi fallback jika probe gagal.

Lanjutan 2: Bagaimana jika C hanya mengalami reordering dan B tiba belakangan pada transmisi aslinya?

Menerima C menghasilkan ACK duplikat 2.000 dan blok SACK yang sesuai. Jika B tiba sebelum ambang batas kehilangan tercapai, ACK kumulatif akan maju dan transmisi ulang dihindari. Jika reordering cukup parah hingga memicu tiga duplikat terlebih dahulu, fast retransmit klasik bisa jadi spurious (palsu). RACK menggunakan window reordering berbasis waktu untuk mengurangi mode kegagalan ambang batas paket tetap ini.

Lanjutan 3: Mengapa SACK lebih berharga ketika B dan D sama-sama hilang?

Penerima dapat melaporkan blok C dan E yang telah sampai. Pengirim menggunakan informasi tersebut dalam scoreboard celah, melewati rentang yang sudah di-SACK, dan memperbaiki B serta D. Tanpa SACK, ACK kumulatif hanya memperlihatkan celah paling kiri. Reno klasik memiliki lebih sedikit informasi tentang beberapa kehilangan dalam satu window dan mungkin memerlukan ACK parsial atau pada akhirnya RTO.

Lanjutan 4: Jika sampel RTT pertama adalah 120 ms, mengapa tidak menetapkan RTO ke 120 ms?

RTT bervariasi tergantung antrean dan perubahan jalur. RFC 6298 menginisialisasi RTTVAR ke R/2; ketika G tidak lebih besar dari 4 × RTTVAR, RTO mentahnya adalah R + 4 × R/2 = 3R. Nilainya adalah 360 ms di sini, dan RFC merekomendasikan pembulatan ke atas menjadi setidaknya satu detik. Menggunakan satu nilai RTT secara langsung akan membuat variasi kecil memicu timeout palsu dan transmisi ulang yang tidak perlu.

Lanjutan 5: Tangkapan paket menunjukkan transmisi ulang tetapi tidak ada tiga ACK duplikat. Apakah itu membuktikan terjadinya RTO?

Tidak. Tangkapan paket mungkin melewatkan ACK pada jalur balik, titik pengamatan mungkin berada sebelum atau sesudah offload, dan stack mungkin menggunakan RACK-TLP atau algoritma pemulihan lainnya. Bandingkan transmisi ulang dengan pewaktuan ACK sebelumnya, periksa SACK dan tail probe, periksa status kernel di sisi pengirim, dan lengkapi bukti dengan tangkapan di sisi penerima.

Lanjutan 6: Mengapa respons kongesti setelah timeout biasanya lebih kuat daripada setelah fast recovery?

Tiga ACK duplikat menunjukkan bahwa segmen-segmen berikutnya berhasil keluar dari jaringan dan mencapai penerima, sehingga clock ACK masih berjalan. RTO dapat mengindikasikan seluruh flight atau jalur umpan balik tidak mengalami kemajuan sama sekali. Oleh karena itu, RFC 5681 klasik mengurangi cwnd menjadi tidak lebih dari satu segmen ukuran penuh dan mengulang slow start setelah timeout, sementara fast recovery mempertahankan sending window yang telah dikurangi.