看看共享鏈路上如何擠占帶寬：
如果 B 倔強地也要保住自己在 start 點的 bw 怎么辦？假設(shè) B 確實通過 inflate inflight 保住了自己原來的 bw，A 又不服又要搶回來怎么辦？來看看這個過程：
多流均保帶寬的代價是高昂的。丟包導(dǎo)致每一個脈沖的能耗白白浪費，而排隊延時則意味著存儲器的能耗。保帶寬的結(jié)果，損人不利己，這里就解釋了。
看個有趣的：Relentless Congestion Control
如果放寬算法的公平性約束，搶帶寬，讓帶寬就自然多了，非常像高速公路的場景了，你想快就快，不太過分且我也沒啥急事就讓讓你，當然，我也一樣。算法的核心是：
instead of applying a multiplicative reduction to cwnd after a loss, cwnd is reduced by the number of lost segments.
完全基于范雅各布森報文守恒，精確填充管道：發(fā)出去 a，丟了 b，cwnd = a - b。relentless cc 承認自己非標：
Relentless Congestion Control conforms to neither the details nor the philosophy of current congestion control standards.
與其它 draft 幾乎無例外想轉(zhuǎn)正不同，relentless cc 甚至不以標準化為目標，只記錄一種可能性：
We are not even planning to standardize it at this time. The goal of the document is to illustrate what new protocol features and properties might be possible if we relax the “TCP-friendly” mandate.
看一下 relentless cc 的工作圖示：
這方式是不是更溫柔呢。
如前述，執(zhí)意保固定帶寬有大代價，只要別硬杠，一般不會有大沖突。流多了就都慢點，自己有需要，隨時 probe，如果大家沒有特別要緊的事非要給你擠回去，一般都會默認的。relentless cc 只是在不停地執(zhí)行 cwnd = cwnd - losses。
非要硬來的話，說說 arq 和 fec，二者結(jié)合效果更好，比方說尾部 fec，重傳 fec。fec 就是提前重傳。既然預(yù)測到丟包率，重傳就是必然的，等到后面實際丟包(這是必然的)再重傳，不如提前重傳，用 fec 的話講就是發(fā)送冗余。但由于擁塞丟包本身就是發(fā)送行為的函數(shù)，擁塞 fec 效果未必好(大概率很差)，無論任何時候擁塞都要謹慎對待。
總有人說不受控的 udp 要比 tcp 快，其實一個優(yōu)秀的 udp-based 協(xié)議并不比 tcp 快，它至少把 tcp 那些東西重新在 udp 上實現(xiàn)了一遍，比如 quic，最后就成了 yat-yet another tcp 了。但凡為 udp 做加法，只能讓它更慢，但慢并不意味著不好，端到端傳輸協(xié)議要全局看。
作者：dog250
轉(zhuǎn)自：https://blog.csdn.net/dog250/article/details/134322441
該文章在 2024/1/27 16:00:42 編輯過
400 186 1886
