TCP Delayed ACK Mengurangi Traffic Acknowledgment

Acknowledgment TCP memberikan feedback penting, tetapi mengirim ACK terpisah untuk setiap segmen data yang masuk tidak selalu diperlukan. Receiver dapat menunda acknowledgment sebentar sehingga satu ACK mencakup lebih dari satu segmen. Perilaku ini dikenal sebagai delayed acknowledgment, atau delayed ACK.

Mekanisme ini mengurangi pemrosesan paket dan traffic reverse-path selama transfer data yang stabil. Mekanisme ini juga memperkenalkan tradeoff timing: jika segmen lain tidak tiba cukup cepat, receiver pada akhirnya harus mengirim ACK yang tertunda secara mandiri.

Karena itu, delayed ACK bukan permintaan untuk menahan acknowledgment dalam waktu lama. Ini adalah mekanisme efisiensi dengan batas waktu yang timing-nya berinteraksi dengan congestion control, pola traffic aplikasi, dan loss recovery.

Acknowledgment TCP bersifat kumulatif

Nomor acknowledgment TCP mengidentifikasi sequence number berikutnya yang diharapkan receiver. Dalam byte stream in-order biasa, hal ini membuat acknowledgment bersifat kumulatif. Sebuah ACK dapat mengonfirmasi penerimaan semua data contiguous sebelum titik acknowledgment yang diiklankan tanpa memerlukan konfirmasi independen untuk setiap segmen.

Properti ini membuka ruang untuk agregasi. Jika dua segmen berukuran penuh tiba secara berurutan, receiver sering kali dapat mengakui keduanya dengan satu ACK alih-alih mengembalikan ACK setelah setiap segmen.

Penghematannya mungkin terlihat kecil untuk satu koneksi karena ACK tanpa data aplikasi merupakan paket yang ringkas. Namun pada skala besar, lebih sedikit paket ACK dapat berarti bandwidth reverse-path yang lebih rendah, lebih sedikit event pemrosesan paket, serta lebih sedikit interrupt atau operasi scheduling tergantung host dan network stack.

Manfaatnya sangat jelas selama transfer satu arah berukuran besar. Data path membawa banyak segmen ke satu arah sementara reverse path terutama membawa acknowledgment. Mengurangi laju ACK dapat menurunkan overhead tanpa mengubah semantik reliability byte stream.

Receiver menunggu data tambahan atau timer

Receiver delayed ACK tidak sekadar menghilangkan acknowledgment. Receiver melacak data yang masih perlu diakui dan mengirim ACK ketika trigger yang relevan terjadi.

Untuk stream segmen berukuran penuh, panduan standar mengharuskan ACK setidaknya setiap segmen penuh kedua atau setelah 2*RMSS byte data baru. Receiver juga tidak boleh membiarkan data pertama yang belum diakui menunggu tanpa batas. Spesifikasi TCP saat ini mengharuskan delay tetap di bawah 0,5 detik.

Implementasi nyata sering menggunakan timer yang lebih pendek dan kebijakan khusus stack. Nilai 0,5 detik adalah batas atas protokol, bukan pernyataan bahwa setiap delayed ACK menunggu selama itu.

Transfer stabil sederhana karena itu dapat menghasilkan pola berulang: satu segmen tiba dan memulai acknowledgment tertunda, segmen kedua tiba sebelum timer berakhir, lalu receiver segera mengirim satu ACK kumulatif yang mencakup keduanya.

Jika segmen kedua tidak pernah tiba, timer mencegah segmen pertama tetap tidak diakui terlalu lama.

Lebih sedikit ACK mengubah timing feedback sender

Acknowledgment tidak hanya mengonfirmasi delivery. Sender TCP juga menggunakan ACK yang tiba sebagai sinyal timing dan congestion control.

Selama congestion control, kedatangan ACK membantu mengatur pelepasan data tambahan dan berkontribusi pada pertumbuhan congestion window. Mengurangi frekuensi ACK mengubah ritme feedback tersebut. Karena itu, panduan protokol mengenai delayed ACK membatasi seberapa agresif receiver sebaiknya menggabungkan acknowledgment.

Interaksi ini paling terlihat ketika sender hanya memiliki sedikit data yang memenuhi syarat untuk dikirim. Jika hanya satu segmen dikirim dan receiver menunggu sebentar untuk segmen lain sebelum mengakuinya, sender dapat menerima feedback lebih lambat dibandingkan jika ACK dikirim segera.

Untuk bulk transfer dengan banyak segmen yang sudah in-flight, waktu tunggu singkat tersebut sering tersembunyi karena segmen berikutnya tiba dengan cepat dan memicu ACK kumulatif. Untuk pertukaran yang jarang atau window yang sangat terbatas, timer dapat terlihat pada latency atau throughput aplikasi.

Inilah salah satu alasan perilaku delayed ACK tidak dapat dinilai hanya dengan menghitung paket. Pengurangan traffic ACK yang sama dapat memiliki biaya yang nyaris tidak terlihat pada satu workload dan efek timing yang nyata pada workload lain.

Data out-of-order mengubah respons

Delayed acknowledgment terutama cocok untuk delivery in-order normal. Packet loss dan reordering menciptakan kondisi ketika feedback yang lebih cepat bernilai penting.

Ketika segmen tiba di atas gap dalam sequence space, panduan TCP merekomendasikan duplicate ACK segera. Feedback tersebut memberi tahu sender sequence point mana yang masih hilang dan dapat berkontribusi pada fast loss recovery. Menunggu timer delayed ACK normal dalam situasi ini dapat menunda bukti berguna mengenai segmen yang hilang.

ACK segera juga direkomendasikan ketika sebuah segmen mengisi seluruh atau sebagian gap. Sender mendapat manfaat dari informasi cepat bahwa contiguous sequence space receiver telah bergerak maju.

Kasus-kasus ini menunjukkan bahwa delayed ACK bukan timer universal yang diterapkan pada setiap segmen yang diterima. TCP stack mempertimbangkan status receive sequence space dan dapat mengirim acknowledgment segera ketika perilaku transport mendapat manfaat dari feedback yang lebih cepat.

Flow request-response kecil dapat memperlihatkan delay

Protokol request-response dapat mengirim potongan data kecil lalu menunggu reply. Bergantung pada aplikasi, TCP stack, dan pola paket, delayed acknowledgment dapat berinteraksi dengan pertukaran tersebut secara berbeda dari continuous bulk stream.

Jika aplikasi penerima dengan cepat menghasilkan data response, TCP stack mungkin dapat membawa acknowledgment bersama data outbound. Ini umum disebut piggybacking ACK. Satu paket kemudian melayani kebutuhan transport acknowledgment sekaligus delivery aplikasi.

Jika tidak ada data response yang siap dan tidak ada segmen masuk kedua, timer delayed ACK pada akhirnya menyebabkan standalone ACK.

Masalah menjadi lebih terlihat ketika sender sendiri menunggu acknowledgment sebelum mengirim data tambahan. Kebijakan sisi sender yang menahan write kecil dan kebijakan delayed ACK sisi receiver dapat menciptakan jeda yang sebenarnya dapat dihindari pada pola traffic tertentu. Stack modern menyertakan pilihan implementasi yang ditujukan untuk membatasi interaksi yang merugikan, tetapi trace aplikasi masih dapat menunjukkan efek timing yang tampak misterius sampai kedua arah pertukaran TCP diperiksa.

Petunjuk diagnosis praktisnya adalah jeda yang berulang antara segmen data dan ACK-nya ketika tidak ada packet loss atau perubahan route. Packet capture dari kedua endpoint dapat membantu memisahkan kebijakan acknowledgment receiver dari network delay dan scheduling aplikasi.

Kebijakan ACK memengaruhi beban reverse-path

Reverse path tidak selalu setara dengan forward path. Access network, radio link, tunnel, dan sistem lain dapat menyediakan kapasitas atau perilaku queueing yang berbeda di setiap arah.

Laju ACK yang lebih rendah dapat mengurangi tekanan reverse-path selama download besar. Hal ini berguna ketika traffic ACK bersaing dengan paket lain pada upstream link yang terbatas. Pada saat yang sama, pengurangan ACK yang berlebihan dapat membuat feedback sender lebih jarang dan menghasilkan perilaku congestion control yang kurang diinginkan.

Karena itu, tujuannya adalah keseimbangan, bukan jumlah ACK sekecil mungkin. Perilaku delayed ACK standar menghapus acknowledgment yang redundan sambil mempertahankan feedback yang cukup sering untuk operasi TCP normal.

Fitur network offload dapat membuat packet capture lebih rumit. Capture yang diambil di dalam host dapat menunjukkan unit agregat besar atau pola acknowledgment yang berbeda dari paket yang terlihat di wire karena segmentation, receive coalescing, atau offload lain beroperasi di antara TCP stack dan network interface. Kesimpulan diagnosis harus mempertimbangkan titik capture.

Delayed ACK menukar jumlah paket dengan latency terbatas

TCP delayed acknowledgment memanfaatkan semantik ACK kumulatif untuk mengurangi paket yang tidak diperlukan. Selama stream in-order, satu acknowledgment dapat mencakup beberapa segmen, mengurangi reverse traffic dan pemrosesan host tanpa melemahkan jaminan delivery TCP.

Tradeoff-nya adalah timing. Receiver dapat menunggu data tambahan sebentar, tetapi harus menjaga waktu tunggu tersebut tetap terbatas dan sebaiknya memberikan feedback segera pada kondisi seperti delivery out-of-order ketika acknowledgment cepat membantu loss recovery.

Untuk bulk transfer yang sibuk, mekanisme ini sering menghilang dalam aliran paket normal karena segmen tambahan tiba sebelum timer menjadi relevan. Untuk pertukaran yang jarang atau saling bergantung erat, delay dapat terlihat. Kontras tersebut membuat delayed ACK menjadi detail transport kecil dengan efek praktis pada jumlah paket, ritme feedback, dan latency aplikasi.