Teks Indo

Machine Translated by Google TEKS
jaringan 1 dari 34
HANYA
Pengendalian Kemacetan Berbasis BBR
Mengukur
bandwidth
kemacetan
NEAL CARDWELL dan waktu
YUCHUNG CHENG Internet tidak memindahkan propagasi
C.STEPHEN GUNN Secaradata sebagaimanahari
keseluruhan, mestinya.
ini bolak-balik
Sebagian besar sel di dunia
SOHEIL HASSAS YEGANEH
VAN JACOBSON pengguna mengalami penundaan dari detik ke menit;
Wi-Fi publik di bandara dan tempat konferensi seringkali lebih
buruk. Peneliti fisika dan iklim perlu bertukar data berukuran
petabyte dengan kolaborator global, namun infrastruktur
multi-Gbps yang mereka rancang dengan hati-hati sering kali
hanya memberikan kecepatan beberapa Mbps pada jarak
antarbenua.6
Masalah-masalah ini diakibatkan oleh pilihan desain yang

dibuat ketika pengendalian kemacetan TCP dibuat di dunia. 1980-an—
mengartikan kehilangan paket sebagai “kemacetan.”13 Kesetaraan
ini benar pada saat itu tetapi karena keterbatasan teknologi,
bukan prinsip pertama. Ketika NIC (pengontrol antarmuka jaringan)
berevolusi dari Mbps menjadi Gbps dan chip memori dari KB ke GB,
hubungan antara kehilangan paket dan kemacetan menjadi
semakin lemah.
Saat ini pengendalian kemacetan berbasis kerugian TCP—
bahkan dengan teknologi terbaik saat ini, CUBIC11—adalah
penyebab utama masalah ini. Ketika buffer kemacetan besar,
antrian | september-oktober 2016 20

Machine Translated by Google
jaringan 2 dari 34
Kontrol kemacetan berbasis kerugian membuat mereka tetap penuh,

menyebabkan bufferbloat. Ketika buffer kemacetan berukuran kecil,
pengendalian kemacetan berbasis kerugian salah mengartikan kerugian sebagai
sinyal kemacetan, sehingga menghasilkan throughput yang rendah.
Memperbaiki masalah ini memerlukan alternatif pengendalian kemacetan berbasis
kerugian. Menemukan alternatif ini memerlukan pemahaman tentang dari mana dan
bagaimana kemacetan jaringan berasal.
Kemacetan dan Kemacetan

Kapan saja, koneksi TCP (dupleks penuh) mempunyai tepat satu link paling lambat
atau hambatan di setiap arah. Hambatan ini penting karena:
3 Ini menentukan kecepatan pengiriman data maksimum koneksi. Ini adalah sifat
umum dari arus tak mampat (misalnya, bayangkan sebuah jalan bebas hambatan
enam jalur pada jam sibuk dimana sebuah kecelakaan telah mengurangi satu
bagian pendek menjadi satu jalur. Lalu lintas di bagian hulu dari kecelakaan
bergerak tidak lebih cepat daripada lalu lintas yang melalui jalur tersebut).
3 Di sinilah terbentuk antrian yang terus-menerus. Antrian menyusut hanya ketika
tingkat keberangkatan suatu tautan melebihi tingkat kedatangannya. Untuk sebuah
Koneksi berjalan pada kecepatan pengiriman maksimum, semua link di bagian
hulu dari kemacetan memiliki tingkat keberangkatan yang lebih cepat sehingga
antriannya bermigrasi ke kemacetan.
Terlepas dari berapa banyak link yang dilalui suatu koneksi atau berapa
kecepatan masing-masingnya, dari sudut pandang TCP, jalur kompleks yang
sewenang-wenang berperilaku sebagai satu link dengan RTT (waktu pulang-
pergi) dan tingkat kemacetan yang sama. Dua kendala fisik, RTprop (waktu
propagasi bolak-balik) dan BtlBw (bandwidth hambatan), terikat pada kinerja
transportasi. (Jika jalur jaringan adalah pipa fisik,

jaringan 3 dari 34
RTprop adalah panjangnya dan BtlBw adalah diameter

minimumnya.)
Gambar 1 menunjukkan RTT dan variasi kecepatan pengiriman

jumlah data dalam penerbangan (data terkirim tetapi belum
dihargai). Garis biru menunjukkan batasan RTprop,
GAMBAR 1: tarif pengiriman dan waktu pulang pergi vs. dalam penerbangan
1
BDP+
BDP BtlneckBufSize
buffer.buffer
aplikasi terbatas bandwidth terbatas terbatas
kemiringan = 1 / BtlBw
uw
gunitgakrlae p
RTprop
BtlBw
RTprop
genpit
namitraigkn
optimal berbasis kerugian
kemiringan
1/
= Pengoperasian penyumbatan
titik.titik kontrol
di sini beroperasi di sini
jumlah dalam penerbangan

jaringan 4 dari 34
garis hijau pada batasan BtlBw, dan garis merah pada buffer
kemacetan. Pengoperasian di wilayah yang diarsir tidak mungkin
dilakukan karena akan melanggar setidaknya satu batasan.
Transisi antar batasan menghasilkan tiga wilayah berbeda (terbatas
aplikasi, terbatas bandwidth, dan terbatas buffer) dengan perilaku

yang berbeda secara kualitatif.
Ketika tidak ada cukup data dalam penerbangan untuk mengisi pipa,
RTprop menentukan perilaku; Jika tidak, BtlBw mendominasi.
Garis pembatas berpotongan di inflight = BtlBw × RTprop, alias BDP pipa
(bandwidth-delay product). Karena pipa sudah penuh melewati titik ini,
kelebihan inflight – BDP menciptakan antrian di bottleneck, yang
menghasilkan ketergantungan linier RTT pada data inflight yang
ditunjukkan pada grafik di atas. Paket akan dibuang ketika kelebihannya
melebihi kapasitas buffer. Kemacetan hanyalah operasi berkelanjutan di
sebelah kanan jalur BDP, dan pengendalian kemacetan adalah suatu
skema untuk membatasi seberapa jauh rata-rata sambungan
beroperasi ke kanan.
Kontrol kemacetan berbasis kerugian beroperasi di tepi kanan

dari wilayah dengan bandwidth terbatas, memberikan bandwidth yang penuh
kemacetan dengan mengorbankan penundaan yang tinggi dan seringnya kehilangan paket.
Ketika memori mahal, ukuran buffer hanya sedikit lebih besar daripada BDP,
yang meminimalkan penundaan berlebih dari kontrol kemacetan berbasis
kerugian. Penurunan harga memori selanjutnya menghasilkan buffer yang
besarnya lebih besar daripada BDP link ISP, dan bufferbloat yang dihasilkan
menghasilkan RTT dalam hitungan detik, bukan milidetik.9
Tepi kiri wilayah dengan bandwidth terbatas lebih baik

titik operasi daripada kanan. Pada tahun 1979 Leonard Kleinrock16
menunjukkan titik operasi ini optimal, memaksimalkan bandwidth
yang dikirimkan sekaligus meminimalkan penundaan dan kehilangan keduanya

jaringan 5 dari 34
untuk koneksi individu dan untuk jaringan secara keseluruhan8.

Sayangnya, sekitar waktu yang sama Jeffrey M. Jaffe14
Hal ini membuktikan bahwa tidak mungkin membuat algoritma
terdistribusi yang menyatu pada titik operasi ini. Hasil ini mengubah
arah penelitian dari menemukan algoritma terdistribusi yang
mencapai titik operasi optimal Kleinrock hingga menyelidiki
pendekatan berbeda untuk pengendalian kemacetan.
Grup kami di Google menghabiskan waktu berjam-jam setiap

hari untuk memeriksa tangkapan header paket TCP dari seluruh dunia,
untuk memahami anomali perilaku dan patologi. Langkah pertama yang
biasa kita lakukan adalah menemukan karakteristik jalur penting, RTprop
dan BtlBw. Bahwa hal ini dapat disimpulkan dari jejak menunjukkan
bahwa hasil Jaffe mungkin tidak terbatas seperti yang terlihat sebelumnya.
Hasilnya bertumpu pada ambiguitas pengukuran yang mendasar
(misalnya, apakah peningkatan RTT yang diukur disebabkan oleh
perubahan panjang jalur, penurunan bandwidth yang terhambat, atau
peningkatan penundaan antrian dari lalu lintas koneksi lain). Meskipun
tidak mungkin untuk membedakan pengukuran tunggal apa pun,
perilaku koneksi dari waktu ke waktu memberikan cerita yang
lebih jelas, menunjukkan kemungkinan strategi pengukuran
yang dirancang untuk mengatasi ambiguitas.
Menggabungkan pengukuran ini dengan loop servo yang kuat
menggunakan kemajuan sistem kontrol terkini12 dapat menghasilkan
protokol kontrol kemacetan terdistribusi yang bereaksi terhadap
kemacetan sebenarnya, bukan kehilangan paket atau penundaan
antrian sementara, dan menyatu dengan probabilitas tinggi ke titik
operasi optimal Kleinrock. Maka dimulailah pencarian tiga tahun kami
untuk menciptakan pengendalian kemacetan berdasarkan
pengukuran dua parameter yang menjadi ciri suatu jalur:
bandwidth kemacetan dan waktu propagasi pulang pergi, atau BBR.

jaringan 6 dari 34
KARAKTERISASI KEMAMPUAN
Koneksi berjalan dengan throughput tertinggi dan penundaan terendah
ketika (rate balance) tingkat kedatangan paket bottleneck sama
dengan BtlBw, dan (full pipe) total data dalam penerbangan sama
dengan BDP (= BtlBw × RTprop) .
Kondisi pertama menjamin bahwa kemacetan bisa terjadi
berjalan pada pemanfaatan 100 persen. Yang kedua menjamin
tersedianya data yang cukup untuk mencegah terjadinya kemacetan,
namun tidak memenuhi kebutuhan pipa secara berlebihan. Kondisi rate
balance saja tidak menjamin tidak adanya antrian, hanya saja tidak dapat
mengubah ukuran (misalnya, jika koneksi dimulai dengan mengirimkan
Initial Window yang berjumlah 10 paket ke dalam BDP lima paket,
kemudian berjalan tepat pada rate bottleneck. , lima dari 10 paket awal
mengisi pipa sehingga kelebihannya membentuk antrian berdiri di
kemacetan yang tidak dapat dihilangkan). Begitu pula dengan kondisi pipa
yang penuh tidak menjamin tidak adanya antrian (misalnya sambungan
yang mengirimkan BDP dalam semburan BDP/2 mendapat
pemanfaatan kemacetan penuh, namun dengan antrian rata-rata BDP/4).
Satu-satunya cara untuk meminimalkan antrian di kemacetan dan
sepanjang jalur adalah dengan memenuhi kedua kondisi tersebut secara bersamaan.
BtlBw dan RTprop bervariasi sepanjang umur sambungan, sehingga
harus terus diperkirakan. TCP saat ini melacak RTT (interval waktu dari
pengiriman paket data hingga paket tersebut dihargai) karena diperlukan
untuk deteksi kehilangan. Kapan saja t,
di mana ÿ 0 mewakili “noise” yang ditimbulkan oleh antrian di sepanjang

jalur, strategi ack tertunda penerima, agregasi ack, dll. RTprop
adalah properti fisik dari jalur koneksi dan hanya berubah jika jalur
tersebut

jaringan 7 dari 34
perubahan. Karena perubahan jalur terjadi pada skala waktu >>

RTprop, penduga yang tidak bias dan efisien pada waktu T adalah
Yaitu, jendela waktu berjalan min over time WR (yang biasanya puluhan
detik hingga menit).
Tidak seperti RTT, spesifikasi TCP tidak memerlukan

implementasi untuk melacak bandwidth yang terhambat, namun
perkiraan yang baik menghasilkan hasil pelacakan laju pengiriman.
Ketika konfirmasi untuk beberapa paket tiba kembali di pengirim, ia
menyampaikan RTT paket tersebut dan mengumumkan pengiriman data
dalam penerbangan ketika paket tersebut berangkat. Kecepatan pengiriman
rata-rata antara pengiriman dan penerimaan adalah rasio data yang
dikirimkan terhadap waktu yang telah berlalu: deliveryRate =

ÿdelivered/ ÿt. Tarif ini harus ÿ tingkat kemacetan (jumlah kedatangan
diketahui secara pasti sehingga semua ketidakpastian ada di ÿt , yang

harus ÿ interval kedatangan sebenarnya; dengan demikian, rasionya
harus ÿ tingkat pengiriman sebenarnya, yaitu, pada gilirannya ,

dibatasi atas oleh kapasitas kemacetan). Oleh karena itu, tingkat
pengiriman maksimal windowed adalah penduga BtlBw yang efisien dan tidak memihak
dimana jendela waktu WB biasanya enam sampai sepuluh RTT.

TCP harus mencatat waktu keberangkatan setiap paket ke
menghitung RTT. BBR menambah catatan tersebut dengan total data
yang dikirimkan sehingga setiap kedatangan ack menghasilkan
pengukuran RTT dan laju pengiriman yang diubah oleh filter menjadi
perkiraan RTprop dan BtlBw.
Perhatikan bahwa nilai-nilai ini sepenuhnya independen:

jaringan 8 dari 34
RTprop dapat berubah (misalnya, pada perubahan rute) tetapi

masih memiliki hambatan yang sama, atau BtlBw dapat berubah
(misalnya, ketika kecepatan link nirkabel berubah) tanpa
mengubah jalur. (Kemandirian inilah yang menyebabkan
kedua batasan harus diketahui untuk mencocokkan perilaku
pengiriman dengan jalur pengiriman.) Karena RTprop hanya
terlihat di sebelah kiri BDP dan BtlBw hanya di sebelah kanan pada
gambar 1, keduanya mematuhi prinsip ketidakpastian: kapan pun
seseorang dapat diukur, yang lain tidak bisa. Secara intuitif, hal ini
terjadi karena pipa harus diisi berlebihan untuk mengetahui
kapasitasnya, sehingga menimbulkan antrian yang mengaburkan
panjang pipa. Misalnya, aplikasi yang menjalankan protokol
permintaan/respons mungkin tidak pernah mengirimkan cukup
data untuk mengisi pipa dan mengamati BtlBw. Transfer data
massal multi-jam mungkin menghabiskan seluruh masa pakainya
di wilayah dengan bandwidth terbatas dan hanya memiliki satu
sampel RTprop dari RTT paket pertama. Ketidakpastian intrinsik
ini berarti bahwa selain estimator untuk memulihkan dua
parameter jalur, harus ada keadaan yang melacak baik apa yang
dapat dipelajari pada titik operasi saat ini dan, ketika informasi
menjadi usang, bagaimana mencapai titik operasi di mana
informasi tersebut dapat diperoleh. dipelajari kembali.
MENCOCOKAN ALIRAN PAKET DENGAN JALUR PENGIRIMAN

Algoritma inti BBR memiliki dua bagian:
Ketika ack diterima
Setiap pernyataan memberikan pengukuran RTT

dan laju pengiriman baru yang memperbarui perkiraan
RTprop dan BtlBw:

jaringan 9 dari 34
fungsi onAck(paket)
rtt = sekarang - packet.sendtime
perbarui_min_filter(RTpropFilter, rtt)
terkirim += paket.ukuran
waktu_terkirim = sekarang
deliveryRate = (terkirim - paket. terkirim) / (sekarang -
paket. waktu_terkirim)
if (deliveryRate > BtlBwFilter.currentMax
|| ! paket.app_limited)
update_max_filter(BtlBwFilter, Tingkat
Pengiriman)
jika (aplikasi_terbatas_hingga > 0)
app_limited_until - = paket.ukuran
Pemeriksaan if mengatasi masalah ketidakpastian yang dijelaskan

di paragraf terakhir: pengirim mungkin memiliki aplikasi terbatas,
yang berarti aplikasi kehabisan data untuk mengisi jaringan.
Hal ini cukup umum terjadi karena lalu lintas permintaan/respons.
Ketika ada peluang pengiriman tetapi tidak ada data untuk
dikirim, BBR menandai sampel bandwidth yang sesuai sebagai
aplikasi terbatas (lihat kodesemu send() setelahnya). Kode di sini
memutuskan sampel mana yang akan disertakan dalam model bandwidth
sehingga mencerminkan batas jaringan, bukan aplikasi. BtlBw adalah
batas atas yang tegas pada tingkat pengiriman sehingga tingkat
pengiriman yang diukur lebih besar dari perkiraan BtlBw saat ini berarti
perkiraan tersebut terlalu rendah, terlepas dari apakah sampelnya
dibatasi oleh aplikasi atau tidak. Jika tidak, sampel dengan aplikasi
terbatas akan dibuang. (Gambar 1 menunjukkan bahwa di wilayah
yang dibatasi aplikasi, deliveryRate meremehkan BtlBw.
Pemeriksaan ini mencegah pengisian filter BtlBw dengan perkiraan
yang terlalu rendah, yang akan menyebabkan data dikirim terlalu lambat.)

jaringan 10 dari 34
Saat data dikirim
Untuk mencocokkan tingkat kedatangan paket dengan tingkat keberangkatan
link kemacetan, BBR mengatur kecepatan setiap paket data. BBR

harus sesuai dengan tingkat kemacetan , yang berarti kecepatan
merupakan bagian integral dari desain dan fundamental dalam pengoperasian—
pacing_rate adalah parameter kontrol utama BBR. Parameter

sekunder, cwnd_gain, membatasi dalam penerbangan ke kelipatan kecil
BDP untuk menangani patologi jaringan dan penerima yang umum (lihat
bagian selanjutnya tentang ACK Tertunda dan Teregang). Secara konseptual,

rutin pengiriman TCP terlihat seperti kode berikut. (Di Linux, pengiriman
menggunakan disiplin antrian FQ/pacing yang efisien,4 yang memberikan
performa koneksi tunggal laju garis BBR pada tautan multigigabit dan
menangani ribuan koneksi dengan laju laju lebih rendah dengan overhead
CPU yang dapat diabaikan.)
fungsi kirim (paket)

bdp = BtlBwFilter.currentMax
* RTpropFilter.currentMin
jika (dalam penerbangan >= cwnd_gain * bdp)
// menunggu ack atau timeout
kembali
jika (sekarang >= Waktu Pengiriman berikutnya)
paket = nextPacketToSend()
jika (! paket)
app_limited_until = dalam penerbangan
kembali
paket.app_limited =
(app_limited_until > 0)
packet.sendtime = sekarang
paket.terkirim = terkirim

jaringan 11 dari 34
paket.waktu_terkirim = waktu_terkirim
kapal (paket)
nextSendTime = sekarang + ukuran paket /
(pacing_gain *
BtlBwFilter.currentMax)
timerCallbackAt(kirim, nextSendTime)
Perilaku kondisi mapan
Laju dan jumlah pengiriman BBR semata-mata merupakan fungsi dari
perkiraan BtlBw dan RTprop, sehingga filter mengontrol adaptasi selain
memperkirakan kendala kemacetan. Hal ini menciptakan loop kontrol
baru yang ditunjukkan pada gambar 2, yang mengilustrasikan detail RTT (biru),
dalam penerbangan (hijau), dan kecepatan pengiriman (merah) dari 700 mdtk
dari aliran 10-Mbps, 40 mdtk. Garis abu-abu tebal di atas data kecepatan
pengiriman adalah status filter BtlBw max. Struktur segitiga dihasilkan dari
perputaran BBR pacing_gain untuk menentukan apakah BtlBw telah
meningkat. Penguatan yang digunakan untuk setiap bagian siklus
ditampilkan sesuai waktu dengan data yang dipengaruhinya. Penguatan
diterapkan pada RTT sebelumnya, saat data dikirim. Hal ini ditunjukkan
dengan joging horizontal pada deskripsi rangkaian kejadian yang berjalan di
sisi kiri.
BBR meminimalkan penundaan dengan menghabiskan sebagian besar
waktunya dengan satu BDP dalam penerbangan, sesuai dengan perkiraan BtlBw.
Ini memindahkan hambatan ke pengirim sehingga tidak dapat mengamati BtlBw
meningkat. Akibatnya, BBR secara berkala menggunakan interval RTprop pada
pacing_gain > 1, yang meningkatkan kecepatan pengiriman dan penerbangan.
Jika BtlBw tidak berubah, maka antrian dibuat di kemacetan, meningkatkan
RTT, yang menjaga deliveryRate tetap konstan. (Antrian ini dihapus dengan
mengirimkan kompensasi pacing_gain < 1 untuk RTprop berikutnya.) Jika

jaringan 12 dari 34
2 GAMBAR 2: Detail RTT (biru), Inflight (hijau) dan Tarif pengiriman (MERAH).
52.5
pipa penuh sehingga RTT
50.0
meningkat seiring dengan penerbangan
)TdTmR(
47.5
(antrian dibuat)
45.0
42.5
60
55
akp
le
rea)nB
nagnabm d(
50
45 gain > 1
sehingga inflight meningkat
perolehan siklus
1,00 1,00 1,00 1,00 1,00 1,25 0,75 1,00 1,00 1,00 1,00 1,00 1,00 1,25 0,75 1,00 1,00
maks BtlBw × penguatan siklus

digunakan sebagai kecepatan pengiriman ack dari kirim pembaruan filter satu RTT nanti
9.50
9.25
)spbM(WB
9.00
8.75 kedatangan ack menambahkan sampel
ke filter maksimal BtlBw
3.8 4.0 4.2 4.4
Waktu (detik)
BtlBw telah meningkat, deliveryRate meningkat dan maks baru

segera meningkatkan output filter BtlBw, sehingga meningkatkan
kecepatan kecepatan dasar. Dengan demikian, BBR menyatu dengan
tingkat kemacetan baru secara eksponensial. Gambar 3 menunjukkan
efek pada aliran BtlBw 10-Mbps, 40-ms yang tiba-tiba berlipat ganda
menjadi 20 Mbps setelah pengoperasian stabil selama 20 detik (grafik
atas) kemudian turun menjadi 10 Mbps setelah 20 detik berikutnya

jaringan 13 dari 34
Pengoperasian stabil pada 20 Mbps (grafik bawah).

(BBR adalah contoh sederhana dari sistem kendali Max-plus, sebuah
pendekatan baru untuk kendali berdasarkan aljabar nonstandar.12
Pendekatan ini memungkinkan tingkat adaptasi [dikendalikan oleh
perolehan maksimal ] tidak bergantung pada pertumbuhan antrian
[dikendalikan oleh perolehan rata-rata ]. Jika diterapkan pada masalah
ini, hal ini menghasilkan loop kontrol sederhana dan implisit yang
mana adaptasi terhadap perubahan batasan fisik secara otomatis
ditangani oleh filter yang mewakili batasan tersebut. Sistem kontrol
konvensional memerlukan beberapa loop yang dihubungkan oleh mesin
negara yang kompleks untuk mencapai hasil yang sama.)
PERILAKU STARTUP ALIRAN BBR TUNGGAL

Implementasi yang ada menangani kejadian seperti startup,
shutdown, dan pemulihan kerugian dengan algoritma khusus kejadian
dan banyak baris kode. BBR menggunakan kode rinci sebelumnya (di
bagian sebelumnya, Mencocokkan Aliran Paket dengan Jalur
Pengiriman) untuk semuanya, menangani kejadian dengan
mengurutkan melalui serangkaian “status” yang ditentukan oleh tabel
yang berisi satu atau lebih kriteria perolehan dan keluar tetap. .
Sebagian besar waktu dihabiskan dalam status ProbeBW yang dijelaskan
di bagian Perilaku Steady-state. Status Startup dan Drain digunakan pada
awal koneksi (gambar 4). Untuk menangani bandwidth tautan
Internet yang mencakup 12 kali lipat, Startup mengimplementasikan
pencarian biner untuk BtlBw dengan menggunakan penguatan 2/
ln2 untuk menggandakan kecepatan pengiriman sementara
kecepatan pengiriman meningkat. Ini menemukan BtlBw di log2
BDP RTT tetapi menciptakan antrean berlebih hingga 2BDP dalam
prosesnya. Setelah Startup menemukan BtlBw, BBR bertransisi ke
Drain, yang menggunakan kebalikan dari gain Startup untuk menghilangkan kelebiha

jaringan 14 dari 34
GAMBAR 3: Perubahan bandwidth
3
120
dalam penerbangan
RTT
100 1,95x
siklus
memperkirakan
meningkat
80
akR
lTm
e d(
p
(=1.253
)dalam
BW
3
re)T
nagnabm sB
a)n
BtlBw dua kali lipat

hingga 20Mbps memperkirakan
60 dua kali lipat dan
pipa penuh
40
19 20 22
21 Waktu (detik)
200
penerbangan meningkat,
mendorong RTT, hingga
dijepit oleh cwnd_gain
150 20Mbps BtlBw

kali keluar dari filter
pengurangan dalam penerbangan

sB
a)n
re)T
nagnabm akR
lTm
e d(
p
menurunkan RTT yang

100 menurunkan dalam penerbangan…
sampai optimal
BtlBw dibelah dua; pulih
dalam penerbangan tidak
pas di pipa,
50 meningkatkan RTT
40 41 42 43 Waktu 44
(detik)

jaringan 15 dari 34
lalu ke ProbeBW setelah penerbangan turun ke BDP.

Gambar 4 menunjukkan detik pertama dari 10-Mbps, 40-ms
aliran BBR. Plot waktu/urutan menunjukkan kemajuan
pengirim (hijau) dan penerima (biru) vs. waktu. Garis merah
menunjukkan pengirim CUBIC dalam kondisi yang sama. Garis
4
abu-abu vertikal menandai transisi status BBR. Gambar di
bawah menunjukkan RTT dari dua koneksi vs. waktu. Perhatikan
bahwa referensi waktu untuk data ini telah tiba (biru) jadi,
GAMBAR 4: Detik pertama dari aliran BBR 10-Mbps, 40-ms
rintisan mengeringkan
selidiki BW
1,00
0,75
0,50
kctarM
aiB
mir)ku a ia
-cted(t
0,25
0,00
0 0,25 0,50 0,75 1,00
kali (detik)
120 klem cwnd_gain

Penerbangan BBR pukul 3 BDP BBR beroperasi
100 CUBIC beralih dari pada BW penuh dengan
80 eksponensial ke linier tidak ada antrian
60 pertumbuhan dalam penerbangan
RTprop
40
0 0,25 0,50 0,75 1,00

waktu (detik)

jaringan 16 dari 34
Meskipun tampaknya terjadi pergeseran waktu, peristiwa-peristiwa

ditampilkan pada titik di mana BBR belajar darinya dan bertindak.
Grafik bawah pada Gambar 4 kontras dengan BBR dan CUBIC.
Perilaku awalnya serupa, namun BBR benar-benar menguras antrian
startupnya sementara CUBIC tidak bisa. Tanpa model jalur untuk
mengetahui berapa banyak kelebihan dalam penerbangan, CUBIC
membuat pertumbuhan dalam penerbangan menjadi kurang agresif, namun
pertumbuhan terus berlanjut hingga buffer kemacetan terisi dan menjatuhkan
paket atau batas dalam penerbangan penerima (jendela penerimaan TCP) tercapai.
Gambar 5 menunjukkan perilaku RTT selama delapan detik
pertama koneksi yang ditunjukkan pada gambar 4. CUBIC (merah)
mengisi buffer yang tersedia, kemudian berputar dari 70 hingga 100
persen penuh setiap beberapa detik. Setelah startup, BBR (hijau) berjalan
5
tanpa antrian.
GAMBAR 5: 8 detik pertama dari aliran CUBIC dan BBR 10-Mbps, 40-ms
500
kehilangan paket dan
episode pemulihan
400
kemacetan 250 ms
300
batas penyangga
)TdTmR(
200
100
RTprop
0 2 6 8
4 kali (detik)

jaringan 17 dari 34
ALIRAN BBR GANDA BERBAGI Hambatan

Gambar 6 menunjukkan bagaimana throughput individu untuk beberapa aliran
BBR yang berbagi hambatan 100-Mbps/10-ms menyatu menjadi bagian yang
adil. Struktur segitiga yang menghadap ke bawah adalah status koneksi
ProbeRTT yang sinkronisasi mandirinya mempercepat konvergensi akhir.
Perputaran keuntungan ProbeBW (gambar 2) menyebabkan aliran yang

lebih besar menghasilkan bandwidth ke aliran yang lebih kecil, sehingga setiap
orang mempelajari bagiannya secara adil. Hal ini terjadi cukup cepat
(beberapa siklus ProbeBW), meskipun ketidakadilan dapat tetap ada ketika
permulaan yang terlambat melebih-lebihkan RTprop sebagai akibat dari
permulaan ketika aliran lain (sementara) telah membuat antrian.
Untuk mempelajari RTTProp yang sebenarnya, aliran bergerak ke kiri
6
BDP menggunakan status ProbeRTT: ketika perkiraan RTTProp belum
diperbarui (yaitu, dengan mengukur RTT yang lebih rendah) selama beberapa
detik, BBR memasuki ProbeRTT, yang mengurangi inflight
GAMBAR 6: Throughput dari 5 aliran BBR berbagi hambatan
80
60
40
ek(
na)srapublM
adil. adil
membagikan
20
0
0 10 20 30 40 50
waktu (detik)

jaringan 18 dari 34
menjadi empat paket untuk setidaknya satu perjalanan pulang pergi, lalu
kembali ke keadaan sebelumnya. Aliran besar yang masuk ke
ProbeRTT menguras banyak paket dari antrian, sehingga beberapa aliran
melihat RTprop baru (RTT minimum baru). Hal ini membuat perkiraan
RTprop mereka kedaluwarsa pada waktu yang sama, sehingga mereka
memasukkan ProbeRTT bersama-sama, yang membuat penurunan
antrian total lebih besar dan menyebabkan lebih banyak aliran melihat
RTprop baru, dan seterusnya. Koordinasi yang terdistribusi ini adalah
kunci menuju keadilan dan stabilitas.
BBR menyinkronkan aliran di sekitar kejadian yang diinginkan dari
antrian kemacetan yang kosong. Sebaliknya, pengendalian kemacetan
berbasis kerugian menyinkronkan kejadian yang tidak diinginkan seperti
pertumbuhan dan luapan antrian secara berkala, sehingga memperkuat
penundaan dan kehilangan paket.
PENGALAMAN PENERAPAN GOOGLE B4 WAN

Jaringan B4 Google adalah WAN (jaringan area luas) berkecepatan
tinggi yang dibangun menggunakan saklar komoditas.15 Kerugian
pada saklar dengan buffer dangkal ini sebagian besar disebabkan
oleh kedatangan lonjakan lalu lintas kecil secara tidak sengaja. Pada tahun
2015 Google memulai peralihan lalu lintas produksi B4 dari CUBIC ke
BBR. Tidak ada masalah atau regresi yang dialami, dan sejak tahun
2016 semua lalu lintas B4 TCP menggunakan BBR. Gambar 7 menunjukkan
salah satu alasan peralihan: throughput BBR secara konsisten 2 hingga
25 kali lebih besar dibandingkan CUBIC. Kami memperkirakan
peningkatan yang lebih besar lagi namun menemukan bahwa 75 persen
koneksi BBR dibatasi oleh buffer penerimaan TCP kernel, yang
sengaja ditetapkan rendah oleh tim operasi jaringan (8 MB) untuk
mencegah CUBIC membanjiri jaringan dengan kelebihan megabyte dalam
penerbangan (8- MB/200-
ms RTT antarbenua ÿ throughput maks 335-Mbps).

19 dari 34
jaringan
20
•
7 GAMBAR 7: BBR vs. Peningkatan throughput relatif CUBIC
1,00
18
•
0,75
16
•
•
satfiltiablaubmourpk
14 0,50
• KUBIK
BBR
12
•
• 0,25
•
•
10 •
•
•
tupphhgK
tu R
guI/uB BrhhK
oorU B
Tt
• 0
•
8 •
• 1 5 20 100 500 5000
•
•
throughput (Mbps) – skala log
6
4 ••••
••
• ••••••••••••••••
••
•
2
peningkatan 2x •••••••••••••••••••••••••••••••••••••••• •••••••• • •
0
5 10 20 50 100 200 500 1000 2000 5000
Throughput KUBIK (Mbps) – skala log
Menaikkan buffer penerimaan secara manual pada satu jalur AS-

Eropa menyebabkan BBR segera mencapai 2 Gbps, sementara
CUBIC tetap pada 15 Mbps—peningkatan relatif sebesar 133x
yang diprediksi oleh Mathis dkk.17
Gambar 7 menunjukkan BBR vs. Throughput relatif CUBIC

jaringan 20 dari 34
peningkatan; sisipan menunjukkan CDF throughput (fungsi

distribusi kumulatif). Tindakannya berasal dari layanan penyelidik aktif
yang membuka koneksi BBR dan CUBIC persisten ke pusat data jarak
jauh, kemudian mentransfer data sebesar 8 MB setiap menit. Prober
berkomunikasi melalui banyak jalur B4 di dalam dan antara Amerika Utara,

Eropa, dan Asia.
Peningkatan besar ini merupakan konsekuensi langsung dari BBR

tidak menggunakan kerugian sebagai indikator kemacetan. Untuk
mencapai bandwidth penuh, pengendalian kemacetan berbasis kerugian yang
ada memerlukan tingkat kerugian yang lebih kecil dari kuadrat kebalikan dari BDP17
(misalnya, < satu kerugian per 30 juta paket untuk jalur 1-Gbps/100-ms).
Gambar 8 membandingkan goodput terukur pada berbagai tingkat
kerugian. Toleransi kerugian CUBIC adalah properti struktural algoritma,
sedangkan BBR adalah parameter konfigurasi.
Saat tingkat kerugian BBR mendekati perolehan puncak ProbeBW,
kemungkinan pengukuran tingkat pengiriman BtlBw yang sebenarnya turun
tajam, menyebabkan filter maksimal diremehkan.
Gambar 8 menunjukkan BBR vs. Goodput CUBIC untuk aliran 60 detik
pada tautan 100-Mbps/100-ms dengan kehilangan acak 0,001 hingga 50
persen. Throughput CUBIC menurun 10 kali lipat dengan kerugian 0,1
persen dan terhenti total di atas 1 persen.
Throughput maksimum yang mungkin adalah laju tautan dikalikan pecahan
yang dikirimkan (= 1 - lossRate). BBR memenuhi batas ini hingga kerugian
5 persen dan mendekati 15 persen.
PENGALAMAN PENERAPAN EDGE YOUTUBE

BBR sedang diterapkan di server video Google.com dan YouTube. Google
menjalankan eksperimen skala kecil di mana sebagian kecil
pengguna ditetapkan secara acak baik BBR atau CUBIC.
Pemutaran menggunakan BBR

jaringan 21 dari 34
100
GAMBAR 8: BBR vs. Goodput CUBIC mengalami kerugian 8
75
50
ek(
na)srapublM
25
0
0,001 0,01 0,1 12 5 10 2030 50
tingkat kerugian (%) – skala log
menunjukkan peningkatan yang signifikan pada semua metrik kualitas
pengalaman YouTube, mungkin karena perilaku BBR lebih konsisten dan
dapat diprediksi. BBR hanya sedikit meningkatkan throughput koneksi
karena YouTube telah menyesuaikan kecepatan streaming server jauh di bawah
BtlBw untuk meminimalkan kejadian bufferbloat dan rebuffer. Meski begitu,

BBR mengurangi median RTT rata-rata sebesar 53 persen secara global dan
lebih dari 80 persen di negara berkembang. Gambar 9 menunjukkan BBR vs.
Peningkatan RTT median CUBIC dari lebih dari 200 juta koneksi pemutaran
YouTube yang diukur di lima benua selama seminggu.
Lebih dari separuh dari 7 miliar Internet seluler di dunia
langganan terhubung melalui sistem 2.5G 8 hingga 114-kbps,5
yang mengalami masalah yang terdokumentasi dengan baik karena
kecenderungan pengisian penyangga dari pengendalian kemacetan berbasis kerugian.3
Tautan hambatan untuk sistem ini biasanya berada di antara keduanya

jaringan 22 dari 34
9
5
GAMBAR 9: BBR vs. Peningkatan RTT median CUBIC
3
TU
/ KIR
B TR
B K
B
0 1 2 3 4 5 6 KUBIK RTT 7 8 9 10
(detik)
SGSN (melayani node dukungan GPRS)18 dan perangkat seluler.

Perangkat lunak SGSN berjalan pada platform PC standar dengan
memori yang cukup, sehingga sering kali terdapat buffer sebesar
megabita antara Internet dan perangkat seluler. Gambar 10
membandingkan (meniru) penundaan Internet-ke-seluler SGSN untuk
BBR dan CUBIC. Garis horizontal menandai salah satu konsekuensi
yang lebih serius: TCP beradaptasi dengan penundaan RTT yang panjang
kecuali pada paket SYN inisiasi koneksi, yang memiliki batas waktu tetap
yang bergantung pada OS. Ketika perangkat seluler menerima data
massal (misalnya, dari pembaruan aplikasi otomatis) melalui SGSN
dengan buffer besar, perangkat tidak dapat terhubung ke apa pun di
Internet hingga antriannya kosong (paket penerimaan SYN ACK tertunda
lebih lama dari paket yang diterima). batas waktu SYN tetap).
Gambar 10 menunjukkan variasi RTT median kondisi tunak dengan

ukuran buffer tautan pada tautan 128-Kbps/40-ms dengan delapan BBR

jaringan 23 dari 34
10 600
GAMBAR 10: Variasi RTT median kondisi tunak dengan ukuran buffer tautan
400
i)skniteetda(l
200 koneksi baru gagal di Linux/Android
Koneksi baru gagal di Windows/Mac OS/iOS
0
0,15 0,75 1,5 3 6 10
penyangga (MB)
(hijau) atau aliran KUBIK (merah). BBR menjaga antrian mendekati

minimum, tidak bergantung pada ukuran buffer kemacetan dan jumlah
aliran aktif. Aliran CUBIC selalu mengisi buffer, sehingga penundaan
bertambah secara linier seiring dengan ukuran buffer.
BANDWIDTH ADAPTIF SELULER SELULER

Sistem adaptasi seluler bandwidth per pelanggan sebagian didasarkan
pada perkiraan permintaan yang menggunakan antrian paket
yang ditujukan untuk pelanggan. Versi awal BBR disesuaikan untuk
menciptakan antrean yang sangat kecil, yang mengakibatkan koneksi
terhenti pada kecepatan yang rendah. Menaikkan puncak ProbeBW
pacing_gain untuk membuat antrean yang lebih besar menghasilkan lebih
sedikit koneksi yang macet, yang menunjukkan bahwa mungkin saja
terjadi terlalu baik pada beberapa jaringan. Dengan perolehan puncak
1,25 × BtlBw saat ini , tidak ada degradasi yang terlihat dibandingkan
dengan CUBIC di jaringan mana pun.

jaringan 24 dari 34
ACKS TERTUNDA DAN DILUNCURKAN

Jaringan seluler, Wi-Fi, dan broadband kabel sering kali menunda dan
mengumpulkan ACK.1 Ketika penerbangan dalam penerbangan dibatasi pada

satu BDP, hal ini mengakibatkan terhentinya pengurangan throughput.
Menaikkan cwnd_gain ProbeBW menjadi dua memungkinkan BBR untuk
terus mengirim dengan lancar sesuai perkiraan kecepatan pengiriman,

bahkan ketika ACK tertunda hingga satu RTT. Hal ini sebagian besar
menghindari kios.
POLISI TOKEN-BUCKET
Penerapan awal BBR di YouTube mengungkapkan bahwa sebagian besar

ISP di dunia mengacaukan lalu lintas dengan polisi token-bucket.7
Bucket biasanya penuh saat koneksi dimulai sehingga BBR mempelajari

BtlBw jaringan yang mendasarinya, namun setelah bucket kosong, semua paket
yang dikirim lebih cepat daripada laju pengisian bucket (jauh lebih rendah dari
BtlBw) akan dihilangkan. BBR akhirnya mempelajari tingkat pengiriman baru

ini, namun siklus keuntungan ProbeBW menghasilkan kerugian moderat yang
terus menerus. Untuk meminimalkan pemborosan bandwidth upstream dan
peningkatan latensi aplikasi akibat kerugian ini, kami menambahkan deteksi

polisi dan model polisi eksplisit ke BBR. Kami juga secara aktif meneliti
cara-cara yang lebih baik untuk mengurangi dampak buruk yang ditimbulkan
oleh polisi.
KOMPETISI DENGAN PENGENDALIAN KEMAMPUAN BERBASIS KERUGIAN
BBR melakukan konvergensi terhadap sebagian besar bandwidth yang

mengalami kemacetan, baik saat bersaing dengan aliran BBR lainnya atau
dengan pengendalian kemacetan berbasis kerugian. Bahkan ketika
pengendalian kemacetan berbasis kerugian memenuhi buffer yang
tersedia, ProbeBW masih dengan kuat menggerakkan estimasi BtlBw menuju

pembagian aliran yang adil, dan ProbeRTT menemukan bahwa estimasi RTProp tepat

jaringan 25 dari 34
cukup tinggi untuk mencapai konvergensi yang adil.
Namun, buffer router yang tidak dikelola melebihi beberapa BDP
menyebabkan pesaing berbasis kerugian yang berumur panjang membengkak
dalam antrean dan mengambil lebih dari porsi yang seharusnya. Mengurangi
hal ini adalah bidang penelitian aktif lainnya.
KESIMPULAN
Memikirkan kembali pengendalian kemacetan akan memberikan manfaat yang
besar. Daripada menggunakan peristiwa seperti kehilangan atau kepadatan
penyangga, yang hanya berkorelasi lemah dengan kemacetan, BBR memulai
dari model kemacetan formal Kleinrock dan titik operasi optimal yang
terkait. Hasil “ketidakmungkinan” yang mengganggu bahwa parameter penting
dari penundaan dan bandwidth tidak dapat ditentukan secara bersamaan dapat
dihindari dengan mengamati bahwa parameter tersebut dapat diperkirakan
secara berurutan. Kemajuan terbaru dalam teori kontrol dan estimasi
kemudian digunakan untuk membuat loop kontrol terdistribusi sederhana yang
mendekati titik optimal, memanfaatkan jaringan sepenuhnya sambil
mempertahankan antrian kecil. Implementasi BBR Google tersedia di TCP kernel
Linux sumber terbuka dan dijelaskan secara rinci dalam lampiran artikel ini.
BBR diterapkan pada tulang punggung B4 Google, dan semakin membaik
throughput dengan urutan besarnya dibandingkan dengan CUBIC.
Teknologi ini juga diterapkan pada server Web Google dan YouTube,
sehingga secara signifikan mengurangi latensi di lima benua yang diuji
hingga saat ini, dan yang paling signifikan adalah di wilayah berkembang. BBR
berjalan murni pada pengirim dan tidak memerlukan perubahan pada
protokol, penerima, atau jaringan, sehingga dapat diterapkan secara
bertahap. Itu hanya bergantung pada RTT dan pengakuan pengiriman paket,
sehingga bisa saja terjadi

jaringan 26 dari 34
diimplementasikan untuk sebagian besar protokol transport Internet.

Penulis dapat dihubungi di https://googlegroups.
com/d/forum/bbr-dev.
Ucapan Terima Kasih

Penulis berterima kasih kepada Len Kleinrock karena telah
menunjukkan cara yang benar untuk melakukan pengendalian
kemacetan. Kami berhutang budi kepada Larry Brakmo atas karya
perintis pengendalian kemacetan Vegas2 dan New Vegas yang
mencerminkan banyak elemen BBR, dan atas saran dan
bimbingan selama pengembangan awal BBR. Kami juga ingin
mengucapkan terima kasih kepada Eric Dumazet, Nandita Dukkipati,
Jana Iyengar, Ian Swett, M. Fitz Nowlan, David Wetherall, Leonidas
Kontothanassis, Amin Vahdat, serta tim infrastruktur Google BwE dan
YouTube atas bantuan dan dukungan mereka yang sangat berharga.
Referensi
1. Abrahamsson, M. 2015. Penekanan TCP ACK. milis IETF AQM;

https://www.ietf.org/mail-archive/web/aqm/
saat ini/msg01480.html.
2. Brakmo, LS, Peterson, LL 1995. TCP Vegas: penghindaran
kemacetan ujung ke ujung di Internet global. Jurnal IEEE tentang
Bidang Terpilih dalam Komunikasi 13(8): 1465–1480.
3. Chakravorty, R., Cartwright, J., Pratt, I. 2002. Pengalaman praktis
dengan TCP melalui GPRS. Di IEEE GLOBECOM.
4. Corbet, J. 2013. Ukuran TSO dan penjadwal FQ. LWN.
bersih; https://lwn.net/Articles/564978/.
5. Ericsson. Laporan Mobilitas Ericsson 2015 (Juni); https://
www.ericsson.com/res/docs/2015/ericsson-mobility-report-
june-2015.pdf.

jaringan 27 dari 34
6.ESnet. Penyetelan aplikasi untuk mengoptimalkan internasional

alur kerja astronomi dari NERSC ke LFI-DPC di INAF-OATs; http://
fasterdata.es.net/data-transfer-tools/case-studies/nersc-astronomy/.
7. Flach, T., Papageorge, P., Terzis, A., Pedrosa, L., Cheng, Y., Karim,
T., Katz-Bassett, E., Govindan, R. 2016. Analisis di seluruh
Internet dari kepolisian lalu lintas. Dalam ACM SIGCOMM:

468–482.
8. Gail, R., Kleinrock, L. 1981. Properti invarian dari kekuatan jaringan

komputer. Dalam Catatan Konferensi, Konferensi Internasional
tentang Komunikasi: 63.1.1-
63.1.5.
9. Gettys, J., Nichols, K. 2011. Bufferbloat: buffer gelap di Internet.

antrian 9(11); http://queue.acm.org/
detail.cfm?id=2071893.
10. Ha, S., Rhee, I. 2011. Menjinakkan gajah: TCP baru yang lambat.
Jaringan Komputer 55(9): 2092–2110.
11. Ha, S., Rhee, I., Xu, L. 2008. CUBIC: varian TCP kecepatan tinggi
baru yang ramah TCP. Tinjauan Sistem Operasi ACM SIGOPS
42(5): 64–74.
12. Heidergott, B., Olsder, G.J., Van Der Woude, J. 2014. Max Plus di
Tempat Kerja: Pemodelan dan Analisis Sistem Tersinkronisasi:
Kursus Aljabar Max-Plus dan Penerapannya. Pers
Universitas Princeton.
13. Jacobson, V. 1988. Penghindaran dan pengendalian kemacetan.
Tinjauan Komunikasi Komputer ACM SIGCOMM 18(4): 314–329.
14. Jaffe, J. 1981. Kekuasaan pengontrol aliran tidak dapat didesentralisasi.

Transaksi IEEE pada Komunikasi 29(9): 1301–1306.
15. Jain, S., Kumar, A., Mandal, S., Ong, J., Poutievski, L., Singh,
A., Venkata, S., Wanderer, J., Zhou, J., Zhu, M .,

jaringan 28 dari 34
dkk. 2013. B4: pengalaman dengan WAN yang ditentukan

perangkat lunak yang diterapkan secara global. Tinjauan
Komunikasi Komputer ACM SIGCOMM 43(4): 3–14.
16. Kleinrock, L. 1979. Kekuatan dan aturan praktis
deterministik untuk masalah probabilistik dalam
komunikasi komputer. Dalam Catatan Konferensi,
Konferensi Internasional tentang Komunikasi: 43.1.1-43.1.10.
17. Mathis, M., Semke, J., Mahdavi, J., Ott, T. 1997.
perilaku makroskopis dari algoritma penghindaran
kemacetan TCP. Tinjauan Komunikasi Komputer ACM
SIGCOMM 27(3): 67–82.
18.wikipedia. Jaringan inti GPRS melayani node dukungan
GPRS; https://en.wikipedia.org/wiki/GPRS_core_
jaringan#Serving_GPRS_support_node_.28SGSN.29.
Artikel Terkait
Buffer sisi pengirim dan Kasus untuk Multimedia
Adaptasi
Aiman Erbad dan Charles “Buck” Krasic
http://queue.acm.org/detail.cfm?id=2381998
Anda Tidak Tahu Jack tentang Kinerja Jaringan
Kevin Fall dan Steve McCanne
Tur Terpandu melalui Jaringan Pusat Data

Dennis Abts dan Bob Felderman

jaringan 29 dari 34
Lampiran – Penjelasan Lengkap
MESIN NEGARA UNTUK PROBING SEKUENSIAL

pacing_gain mengontrol seberapa cepat paket dikirim relatif
terhadap BtlBw dan merupakan kunci kemampuan BBR untuk belajar.
Pacing_gain > 1 meningkatkan inflight dan mengurangi waktu antar
kedatangan paket, sehingga memindahkan koneksi ke kanan pada
gambar 1. Pacing_gain < 1 memiliki efek sebaliknya, memindahkan
koneksi ke kiri.
BBR menggunakan pacing_gain ini untuk mengimplementasikan

mesin status probing sekuensial sederhana yang bergantian antara
pengujian untuk bandwidth yang lebih tinggi dan kemudian pengujian
untuk waktu pulang pergi yang lebih rendah. (Tidak perlu menyelidiki
bandwidth yang lebih sedikit karena hal ini ditangani secara otomatis oleh
filter BtlBw max: pengukuran baru mencerminkan penurunan, sehingga
BtlBw akan mengoreksi dirinya sendiri segera setelah pengukuran lama terakhir
kali keluar dari filter. Filter RTprop min secara otomatis menangani
peningkatan panjang jalur dengan cara yang sama.)
Jika bandwidth kemacetan meningkat, BBR harus mengirim
lebih cepat untuk menemukan ini. Demikian pula, jika penundaan

propagasi bolak-balik sebenarnya berubah, hal ini akan mengubah BDP,
dan dengan demikian BBR harus mengirim lebih lambat untuk
mendapatkan penerbangan di bawah BDP guna mengukur RTprop baru.
Oleh karena itu, satu-satunya cara untuk menemukan perubahan ini
adalah dengan menjalankan eksperimen, mengirim lebih cepat untuk
memeriksa peningkatan BtlBw atau mengirim lebih lambat untuk memeriksa
penurunan RTprop. Frekuensi, besaran, durasi, dan struktur eksperimen ini
berbeda-beda bergantung pada apa yang sudah diketahui (startup atau
kondisi stabil) dan perilaku pengiriman aplikasi (intermiten atau berkelanjutan).
PERILAKU STEADY-STATE
Aliran BBR menghabiskan sebagian besar waktunya di

jaringan 30 dari 34
Status ProbeBW, menyelidiki bandwidth menggunakan pendekatan yang
disebut gain cycle, yang membantu aliran BBR mencapai throughput
tinggi, penundaan antrian rendah, dan konvergensi ke bagian bandwidth yang
adil. Dengan perputaran gain, BBR menggilir serangkaian nilai untuk

pacing_gain. Ini menggunakan siklus delapan fase dengan nilai pacing_gain
berikut: 5/4, 3/4, 1, 1, 1, 1, 1, 1. Setiap fase biasanya berlangsung selama
perkiraan RTprop. Desain ini memungkinkan siklus penguatan terlebih
dahulu untuk menyelidiki bandwidth yang lebih banyak dengan pacing_gain di

atas 1,0, kemudian menguras antrian yang dihasilkan dengan pacing_gain
dengan jarak yang sama di bawah 1,0, dan kemudian berlayar dengan antrian
pendek menggunakan pacing_gain 1,0. Gain rata-rata di semua fase
adalah 1,0 karena ProbeBW bertujuan agar laju kecepatan rata-ratanya sama
dengan bandwidth yang tersedia dan dengan demikian mempertahankan
pemanfaatan yang tinggi, sekaligus mempertahankan antrian yang kecil dan
terbatas. Perhatikan bahwa meskipun gain cycle memvariasikan nilai
pacing_gain, cwnd_
Perolehan tetap konstan pada angka dua, karena ack yang tertunda dan
diregangkan dapat menyerang kapan saja (lihat bagian mengenai Ack yang
Tertunda dan Meregangkan).
Lebih jauh lagi, untuk meningkatkan pencampuran dan keadilan,
dan untuk mengurangi antrean ketika beberapa aliran BBR mengalami
hambatan yang sama, BBR mengacak fase perputaran penguatan ProbeBW
dengan memilih fase awal secara acak—dari semua fase kecuali fase 3/4—
ketika memasuki ProbeBW. Mengapa tidak mulai bersepeda dengan 3/4?
Keuntungan utama dari 3/4 pacing_gain adalah untuk menguras antrian
apa pun yang dapat dibuat dengan menjalankan 5/4 pacing_gain ketika pipa
sudah penuh.
Saat keluar dari Drain atau ProbeRTT dan masuk ke ProbeBW, tidak ada
antrian untuk dikuras, sehingga penguatan 3/4 tidak memberikan keuntungan
tersebut. Menggunakan 3/4 dalam konteks tersebut hanya memiliki biaya:

pemanfaatan tautan untuk putaran 3/4 tersebut, bukan 1.

jaringan 31 dari 34
Karena memulai dengan 3/4 akan menimbulkan biaya tetapi tidak

ada manfaatnya, dan karena memasuki ProbeBW terjadi pada awal
koneksi apa pun yang cukup lama untuk memiliki Drain, BBR
menggunakan optimasi kecil ini.
Aliran BBR bekerja sama untuk menguras antrian
kemacetan secara berkala menggunakan status yang disebut
ProbeRTT. Dalam keadaan apa pun selain ProbeRTT itu sendiri, jika
perkiraan RTP belum diperbarui (yaitu, dengan mendapatkan
pengukuran RTT yang lebih rendah) selama lebih dari 10 detik, maka
BBR memasuki ProbeRTT dan mengurangi cwnd ke nilai yang

sangat kecil (empat paket). Setelah mempertahankan jumlah minimum
paket dalam penerbangan setidaknya selama 200 ms dan satu
perjalanan pulang pergi, BBR meninggalkan ProbeRTT dan bertransisi
ke Startup atau ProbeBW, bergantung pada apakah perkiraan pipa
sudah terisi.
BBR dirancang untuk menghabiskan sebagian besar waktunya
(sekitar 98 persen) di ProbeBW dan sisanya di ProbeRTT, berdasarkan
serangkaian trade-off. ProbeRTT bertahan cukup lama (setidaknya
200 mdtk) untuk memungkinkan aliran dengan RTT berbeda
memiliki status ProbeRTT yang tumpang tindih, namun tetap cukup

singkat untuk membatasi penalti kinerja pembatasan cwnd ProbeRTT
menjadi sekitar 2 persen (200 mdtk/10 detik).
Jendela filter RTprop (10 detik) cukup singkat untuk memungkinkan
konvergensi cepat jika tingkat lalu lintas atau rute berubah, namun
cukup lama sehingga aplikasi interaktif (misalnya, halaman Web,
panggilan prosedur jarak jauh, potongan video) sering kali memiliki
keheningan alami atau kecepatan rendah Periode dalam jendela
dimana laju aliran cukup rendah atau cukup lama untuk mengalirkan
antriannya ke dalam kemacetan. Kemudian filter RTprop secara
oportunistik mengambil pengukuran RTprop ini, dan RTProp
menyegarkan tanpa memerlukan ProbeRTT. Ini

jaringan 32 dari 34
Caranya, aliran biasanya hanya perlu membayar denda 2 persen jika

ada beberapa aliran massal yang sibuk mengirim ke seluruh jendela
RTProp.
PERILAKU STARTUP
Ketika aliran BBR dimulai, ia melakukan proses probe/drain
berurutan yang pertama (dan paling cepat). Bandwidth tautan jaringan
berkisar antara 1012—dari beberapa bit hingga 100 gigabit per
detik. Untuk mempelajari BtlBw, mengingat rentang yang sangat besar
untuk dijelajahi, BBR melakukan pencarian biner pada rate space. Ini
menemukan BtlBw dengan sangat cepat (log2 BDP bolak-balik) tetapi
mengorbankan pembuatan antrian 2BDP pada langkah terakhir
pencarian. Status Startup BBR melakukan pencarian ini dan kemudian
status Drain menguras antrian yang dihasilkan.
Pertama, Startup meningkatkan kecepatan pengiriman secara
eksponensial, menggandakannya setiap putaran. Untuk mencapai
probing cepat ini dengan cara yang sehalus mungkin, di Startup,
pacing_gain dan cwnd_gain diatur ke 2/ln2, nilai minimum yang
memungkinkan kecepatan pengiriman menjadi dua kali lipat setiap
putaran. Setelah pipa penuh, cwnd_gain membatasi antrian menjadi
(cwnd_gain - 1) x BDP.
Selama Startup, BBR memperkirakan apakah pipa sudah penuh

dengan mencari dataran tinggi dalam perkiraan BtlBw. Jika ia
mengetahui bahwa ada beberapa (tiga) putaran di mana upaya untuk
menggandakan tingkat pengiriman sebenarnya hanya menghasilkan
sedikit peningkatan (kurang dari 25 persen), maka ia memperkirakan
bahwa ia telah mencapai BtlBw dan keluar dari Startup dan memasuki
Drain. BBR menunggu tiga putaran untuk mendapatkan bukti kuat
bahwa pengirim tidak mendeteksi dataran tinggi tingkat pengiriman yang

untuk sementara diberlakukan oleh jendela penerimaan.
Mengizinkan tiga putaran memberikan waktu untuk penyetelan otomatis jendela pen

jaringan 33 dari 34
untuk membuka jendela penerimaan dan agar pengirim BBR menyadari bahwa BtlBw
harus lebih tinggi: pada putaran pertama algoritma penyetelan otomatis jendela
penerimaan menumbuhkan jendela penerimaan; Pada putaran kedua pengirim
mengisi jendela penerimaan yang lebih tinggi; Pada putaran ketiga pengirim
mendapatkan sampel dengan tingkat pengiriman yang lebih tinggi. Ambang batas tiga
putaran ini divalidasi oleh data eksperimen YouTube.
Di Drain, BBR bertujuan untuk dengan cepat menguras antrian apa pun yang dibuat
Startup dengan beralih ke pacing_gain yang merupakan kebalikan dari nilai yang
digunakan selama Startup, yang menguras antrian dalam satu putaran. Bila jumlah paket
dalam penerbangan sesuai dengan estimasi BDP, berarti BBR memperkirakan antrian
sudah terkuras seluruhnya namun pipa masih penuh, maka BBR keluar dari Drain dan
masuk ke ProbeBW.
Perhatikan bahwa Startup BBR dan startup CUBIC yang lambat mengeksplorasi
kapasitas kemacetan secara eksponensial, menggandakan tingkat pengiriman
mereka setiap putaran; Namun keduanya berbeda dalam banyak hal. Pertama, BBR
lebih kuat dalam menemukan bandwidth yang tersedia, karena BBR tidak keluar dari
pencarian saat paket hilang atau (seperti pada Hystart10 CUBIC) peningkatan
penundaan. Kedua, BBR dengan lancar mempercepat kecepatan pengirimannya,
sementara dalam setiap putaran CUBIC (bahkan dengan pacing) mengirimkan
serangkaian paket dan kemudian menerapkan gap of silence. Gambar 4
menunjukkan jumlah paket dalam penerbangan dan RTT yang diamati pada
setiap pengakuan untuk BBR dan CUBIC.
REAKSI TERHADAP TRANSIEN

Jalur jaringan dan lalu lintas yang melewatinya dapat membuat perubahan dramatis
secara tiba-tiba. Untuk beradaptasi dengan hal ini dengan lancar dan kuat, serta
mengurangi kehilangan paket dalam kasus seperti itu, BBR menggunakan sejumlah
strategi untuk mengimplementasikan model inti. Pertama,

jaringan 34 dari 34
BBR memperlakukan cwnd_gain x BDP sebagai target yang didekati

cwnd saat ini dengan hati-hati dari bawah, meningkatkan cwnd tidak
lebih dari jumlah data yang maju setiap saat. Kedua, pada saat batas
waktu pengiriman ulang habis, yang berarti pengirim menganggap
semua paket dalam penerbangan hilang, BBR secara
konservatif mengurangi cwnd menjadi satu paket dan mengirimkan
satu paket (seperti algoritma kontrol kemacetan berbasis kerugian
seperti CUBIC). Terakhir, ketika pengirim mendeteksi paket
hilang namun masih ada paket dalam penerbangan, pada putaran
pertama proses perbaikan kehilangan, BBR untuk sementara mengurangi
kecepatan pengiriman agar sesuai dengan kecepatan pengiriman
saat ini; pada putaran kedua dan selanjutnya dari perbaikan kerugian,
hal ini memastikan kecepatan pengiriman tidak pernah melebihi dua kali
lipat kecepatan pengiriman saat ini. Hal ini secara signifikan mengurangi
kerugian sementara ketika BBR bertemu dengan polisi atau bersaing
dengan aliran lain dalam buffer skala BDP.
Para penulis adalah anggota proyek make-tcp-fast Google, yang

bertujuan untuk mengembangkan transportasi Internet melalui
penelitian mendasar dan perangkat lunak sumber terbuka.
Kontribusi proyek termasuk TFO (TCP Fast Open), TLP (Tail Loss
Probe), pemulihan kerugian RACK, fq/ pacing, dan sebagian besar
komitmen git pada kode TCP kernel Linux selama lima tahun terakhir.

Teks Indo

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Teks Indo

Diunggah oleh

Hak Cipta:

Format Tersedia

Machine Translated by Google TEKS

Pengendalian Kemacetan Berbasis BBR

Masalah-masalah ini diakibatkan oleh pilihan desain yang

antrian | september-oktober 2016 20

Kontrol kemacetan berbasis kerugian membuat mereka tetap penuh,

pengendalian kemacetan berbasis kerugian salah mengartikan kerugian sebagai

sinyal kemacetan, sehingga menghasilkan throughput yang rendah.

Memperbaiki masalah ini memerlukan alternatif pengendalian kemacetan berbasis

bagaimana kemacetan jaringan berasal.

Kemacetan dan Kemacetan

3 Di sinilah terbentuk antrian yang terus-menerus. Antrian menyusut hanya ketika

tingkat keberangkatan suatu tautan melebihi tingkat kedatangannya. Untuk sebuah

Koneksi berjalan pada kecepatan pengiriman maksimum, semua link di bagian

antriannya bermigrasi ke kemacetan.

kecepatan masing-masingnya, dari sudut pandang TCP, jalur kompleks yang

sewenang-wenang berperilaku sebagai satu link dengan RTT (waktu pulang-

propagasi bolak-balik) dan BtlBw (bandwidth hambatan), terikat pada kinerja

transportasi. (Jika jalur jaringan adalah pipa fisik,

antrian | september-oktober 2016 21

RTprop adalah panjangnya dan BtlBw adalah diameter

Gambar 1 menunjukkan RTT dan variasi kecepatan pengiriman

aplikasi terbatas bandwidth terbatas terbatas

optimal berbasis kerugian

jumlah dalam penerbangan

antrian | september-oktober 2016 22

aplikasi, terbatas bandwidth, dan terbatas buffer) dengan perilaku

Kontrol kemacetan berbasis kerugian beroperasi di tepi kanan

Tepi kiri wilayah dengan bandwidth terbatas lebih baik

antrian | september-oktober 2016 23

untuk koneksi individu dan untuk jaringan secara keseluruhan8.

Grup kami di Google menghabiskan waktu berjam-jam setiap

antrian | september-oktober 2016 24

di mana ÿ 0 mewakili “noise” yang ditimbulkan oleh antrian di sepanjang

antrian | september-oktober 2016 25

perubahan. Karena perubahan jalur terjadi pada skala waktu >>

Tidak seperti RTT, spesifikasi TCP tidak memerlukan

dikirimkan terhadap waktu yang telah berlalu: deliveryRate =

diketahui secara pasti sehingga semua ketidakpastian ada di ÿt , yang

harus ÿ tingkat pengiriman sebenarnya, yaitu, pada gilirannya ,

dimana jendela waktu WB biasanya enam sampai sepuluh RTT.

antrian | september-oktober 2016 26

RTprop dapat berubah (misalnya, pada perubahan rute) tetapi

MENCOCOKAN ALIRAN PAKET DENGAN JALUR PENGIRIMAN

Ketika ack diterima

Setiap pernyataan memberikan pengukuran RTT

antrian | september-oktober 2016 27

Pemeriksaan if mengatasi masalah ketidakpastian yang dijelaskan

antrian | september-oktober 2016 28

Saat data dikirim

Untuk mencocokkan tingkat kedatangan paket dengan tingkat keberangkatan

link kemacetan, BBR mengatur kecepatan setiap paket data. BBR

pacing_rate adalah parameter kontrol utama BBR. Parameter

bagian selanjutnya tentang ACK Tertunda dan Teregang). Secara konseptual,

fungsi kirim (paket)

antrian | september-oktober 2016 29

Perilaku kondisi mapan

Laju dan jumlah pengiriman BBR semata-mata merupakan fungsi dari

perkiraan BtlBw dan RTprop, sehingga filter mengontrol adaptasi selain

memperkirakan kendala kemacetan. Hal ini menciptakan loop kontrol

perputaran BBR pacing_gain untuk menentukan apakah BtlBw telah

meningkat. Penguatan yang digunakan untuk setiap bagian siklus

ditampilkan sesuai waktu dengan data yang dipengaruhinya. Penguatan

dengan joging horizontal pada deskripsi rangkaian kejadian yang berjalan di