congestion-control

0熱度

1回答

這是一個傳送帶系統。箱子在A處進入系統並朝C離開系統。對於B-> D也是如此。路徑A-> C上的框比框B-> D具有更高的優先級。盒子可以在每個廣場停下來等待。如果在A2和B2上有一個框，則A2中的一個應該先經過X. 如果在C2，C1，A2和B2上有框，那麼B2中的框應該穿過X並在A2框上等待，直到C1爲空。否則它會阻塞路徑B-> D。如何用神經網絡解決這個問題？因此，我想輸入每個塊的當前狀

-1熱度

1回答

什麼是Linux中目前流行的TCP擁塞控制算法

TCP裏諾，HSTCP，STCP或快速TCP？或者我們可以改變目前流行的內核算法？

-1熱度

1回答

TCP擁塞窗口大小太大？

我嘗試使用Mininet模擬由2臺主機和1臺交換機組成的網絡。一臺主機是發送方，通過使用iperf工具連續發送數據包到另一臺主機（接收方）。 H1 ---------------------------- Switch ---------------- ---------- H2 ------- 100Mbps | 0.125ms ----------- 100Mbps | 0.125ms --

-1熱度

1回答

如何在沒有丟包的情況下計算TFRC（TCP友好速率控制）中的丟失事件率p？

當有包丟失時，我知道計算p的方法（我在RFC文檔中讀到）。但是當沒有丟包時，如何計算它呢？該文件沒有顯示任何關於它。如果丟失事件率p是零，在TFRC等式的分母爲0。的方程如下： enter image description here 和文檔是rfc5348：https://tools.ietf.org/html/rfc5348

0熱度

1回答

爲什麼在終端主機部署擁塞控制

爲什麼在發送方節點部署擁塞控制流程？我知道避免在路由器上部署擁塞控制的一個限制是路由器需要維護流量狀態，這會增加路由器的負擔。把這一點放在一邊，是否有限制在路由器端部署擁塞的其他缺陷？

3熱度

2回答

sshuttle如何避免TCP-over-TCP詛咒？

sshuttle claims它可以解決很多discussed problem的TCP-over-TCP meltdown。 sshuttle在本地組裝TCP流，通過ssh會話將其狀態複用，並在另一端將其拆分回數據包。所以它永遠不會結束TCP-over-TCP。這只是TCP數據，這是安全的。但是從程序的角度來看，它維護一個與目標服務器的TCP連接（讀取指數超時），這是關於其他TCP會話的分層，因

-1熱度

1回答

這是UDP可行性/聲音的擁塞控制方法嗎？

發件人發送數據。接收機等待幾秒鐘，然後計算吞吐速率/ s的接收器發送在該其接收數據包（字節/秒），以發送者發件人計算其發送的分組的速率如果速率發送者的速率明顯更高，將其降低到匹配接收速率。或者，更先進的方法：發件人開始於預定的最小速率（例如1KB /秒。）接收器發送所計算出的接收率回發送者發送。如果接收速率與發送速率相同（考慮到延遲），則按設定的比例增加速率（例如速率* 2）繼續

-1熱度

2回答

隊列長度是否真的影響DCTCP中的延遲？

DCTCP是適用於數據中心環境的TCP變體。 The source is here DCTCP在商品交換機中使用ECN功能來限制交換機中緩衝區的隊列長度在閾值K附近。這樣做很少會發生數據包丟失，因爲K遠小於緩衝區的容量，所以緩衝區幾乎不滿。 DCTCP實現小流量低延遲，同時保持大流量高吞吐量。原因是當隊列長度超過閾值K時，將發送擁塞通知給發件人。在發送方，隨着時間的推移計算擁塞概率的值，因此發送方

5熱度

2回答

TCP接收窗口大小高於net.core.rmem_max

我正在運行iperf兩臺服務器之間的測量，通過10Gbit鏈接連接。我試圖將我觀察到的最大窗口大小與系統配置參數相關聯。特別是，我觀察到最大窗口大小爲3 MiB。但是，我無法在系統文件中找到相應的值。通過運行sysctl -a我得到以下值： net.ipv4.tcp_rmem = 4096 87380 6291456 net.core.rmem_max = 212992 第一個值告訴我

1熱度

1回答

TCP擁塞算法 - Tcp Westwood或Tcp westwood plus？

我在我的linux 2.16.36中執行了這個「ls/lib/modules/uname -r/kernel/net/ipv4/」。在那裏我可以看到算法列表.tcp_westwood列在該列表中。那是tcp_westwood還是tcp_westwood +？