add token into stream

[cs8425]

18

解決一個慢的stream餓死其他stream的問題 保留原本的token來控制總buffer的使用量 除非夠慢又夠多的stream才會造成餓死的問題 (stream的MaxBuffer * N >= session的MaxBuffer)

config的預設值目前我是抓比較高, 可以看情況調整 每個Session最多16MB (MaxReceiveBuffer) 每個Stream最多16kB (MaxStreamBuffer) Stream buffer小於4kB的時候允許對面寫入新資料 (MinStreamBuffer) 預設值能允許1024個慢速stream才會造成餓死 假設不被惡意攻擊(對面無視cmdFUL控制封包繼續傳) 此情況下記憶體使用量 ~= 16MB

[xtaci]

你这样做最大的传输速度被限制在 16KB/RTT了

[cs8425]

實測過並不會限制在16KB/RTT 設成16KB, 4MB, ping 12ms, 一樣跑到94Mbps(我這邊的頻寬上限100Mbps) 設成4KB, 4MB, 下降為70Mbps 只有stream read的速度<對面傳的速度才會受制於stream的buffer

[xtaci]

你这个ping值太小，如果ping值一大，比如200ms，你速度就下来了

[cs8425]

我去租一台ping 200ms的主機試試@@ 晚點再回報 不知道有沒有更好的模擬方法?

[cs8425]

scaleway的巴黎主機(VC1S)實測 ping 300~350ms的情況下差異並沒有很大 kcptun為master直接clone下來編譯的 只有smux有差異 是否有別的參數/測試建議? ps.如果有需要主機可以直接開帳號給你測試

iperf server端皆為: iperf -s -p 9999 -f M -N socks5 server已確認過不是瓶頸

改過的:

$ iperf -c 127.0.0.1 -p 5002 -f M -N -w 100M -t 60 -i 5
------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 5002
TCP window size: 0.41 MByte (WARNING: requested  100 MByte)
------------------------------------------------------------
[  3] local 127.0.0.1 port 51926 connected with 127.0.0.1 port 5002
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  46.9 MBytes  9.38 MBytes/sec
[  3]  5.0-10.0 sec  40.1 MBytes  8.03 MBytes/sec
[  3] 10.0-15.0 sec  39.5 MBytes  7.90 MBytes/sec
[  3] 15.0-20.0 sec  40.1 MBytes  8.03 MBytes/sec
[  3] 20.0-25.0 sec  40.1 MBytes  8.03 MBytes/sec
[  3] 25.0-30.0 sec  40.8 MBytes  8.15 MBytes/sec
[  3] 30.0-35.0 sec  37.4 MBytes  7.47 MBytes/sec
[  3] 35.0-40.0 sec  42.1 MBytes  8.43 MBytes/sec
[  3] 40.0-45.0 sec  41.6 MBytes  8.32 MBytes/sec
[  3] 45.0-50.0 sec  41.0 MBytes  8.20 MBytes/sec
[  3] 50.0-55.0 sec  40.6 MBytes  8.12 MBytes/sec
[  3] 55.0-60.0 sec  40.9 MBytes  8.18 MBytes/sec
[  3]  0.0-60.1 sec   491 MBytes  8.18 MBytes/sec

原本的:

$ iperf -c 127.0.0.1 -p 5002 -f M -N -w 100M -t 60 -i 5
------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 5002
TCP window size: 0.41 MByte (WARNING: requested  100 MByte)
------------------------------------------------------------
[  3] local 127.0.0.1 port 51940 connected with 127.0.0.1 port 5002
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  45.8 MBytes  9.15 MBytes/sec
[  3]  5.0-10.0 sec  40.5 MBytes  8.10 MBytes/sec
[  3] 10.0-15.0 sec  40.5 MBytes  8.10 MBytes/sec
[  3] 15.0-20.0 sec  40.6 MBytes  8.12 MBytes/sec
[  3] 20.0-25.0 sec  40.1 MBytes  8.03 MBytes/sec
[  3] 25.0-30.0 sec  40.4 MBytes  8.07 MBytes/sec
[  3] 30.0-35.0 sec  40.9 MBytes  8.18 MBytes/sec
[  3] 35.0-40.0 sec  40.1 MBytes  8.03 MBytes/sec
[  3] 40.0-45.0 sec  40.2 MBytes  8.05 MBytes/sec
[  3] 45.0-50.0 sec  40.9 MBytes  8.18 MBytes/sec
[  3] 50.0-55.0 sec  41.0 MBytes  8.20 MBytes/sec
[  3] 55.0-60.0 sec  40.6 MBytes  8.12 MBytes/sec
[  3]  0.0-60.0 sec   492 MBytes  8.19 MBytes/sec

client設定

2017/04/25 17:45:30 main.go:283: version: SELFBUILD
2017/04/25 17:45:30 main.go:319: listening on: 127.0.0.1:5002
2017/04/25 17:45:30 main.go:320: encryption: salsa20
2017/04/25 17:45:30 main.go:321: nodelay parameters: 0 30 2 1
2017/04/25 17:45:30 main.go:322: remote address: 212.47.246.125:5001
2017/04/25 17:45:30 main.go:323: sndwnd: 128 rcvwnd: 512
2017/04/25 17:45:30 main.go:324: compression: true
2017/04/25 17:45:30 main.go:325: mtu: 1350
2017/04/25 17:45:30 main.go:326: datashard: 1 parityshard: 0
2017/04/25 17:45:30 main.go:327: acknodelay: true
2017/04/25 17:45:30 main.go:328: dscp: 0
2017/04/25 17:45:30 main.go:329: sockbuf: 16777216
2017/04/25 17:45:30 main.go:330: keepalive: 10
2017/04/25 17:45:30 main.go:331: conn: 1
2017/04/25 17:45:30 main.go:332: autoexpire: 0
2017/04/25 17:45:30 main.go:333: scavengettl: 0
2017/04/25 17:45:30 main.go:334: snmplog: 
2017/04/25 17:45:30 main.go:335: snmpperiod: 60

server設定:

2017/04/25 09:45:29 main.go:297: version: SELFBUILD
2017/04/25 09:45:29 main.go:330: listening on: [::]:5001
2017/04/25 09:45:29 main.go:331: target: 127.0.0.1:9999
2017/04/25 09:45:29 main.go:332: encryption: salsa20
2017/04/25 09:45:29 main.go:333: nodelay parameters: 0 50 0 0
2017/04/25 09:45:29 main.go:334: sndwnd: 1024 rcvwnd: 1024
2017/04/25 09:45:29 main.go:335: compression: true
2017/04/25 09:45:29 main.go:336: mtu: 1350
2017/04/25 09:45:29 main.go:337: datashard: 1 parityshard: 0
2017/04/25 09:45:29 main.go:338: acknodelay: true
2017/04/25 09:45:29 main.go:339: dscp: 0
2017/04/25 09:45:29 main.go:340: sockbuf: 16777216
2017/04/25 09:45:29 main.go:341: keepalive: 10
2017/04/25 09:45:29 main.go:342: snmplog: 
2017/04/25 09:45:29 main.go:343: snmpperiod: 60
2017/04/25 09:45:29 main.go:344: pprof: false

[xtaci]

看了下，session.token你没有去掉， 总阀门没有关啊。 只是在当前的基础上，还增加了限速。

[xtaci]

我明白你的意思了，你是想通过接收方发送控制信息，告诉发送方停止推流。

发送方必须要执行cmdFUL,cmdEMP进行阻塞。

这种方法的主要的问题就是可能造成限速， 最终 cmdFUL, cmdEMP会成为驱动下一次数据发送的时钟信号，这个时钟信号的间隔就是RTT。

你上面的测试是一个快速的consumer，可能并没有触发到cmdFUL/EMP。也就和原来一样的结果。

[cs8425]

session.token沒去掉是為了限制記憶體的總使用量 限速是針對個別的stream 讀取慢的stream可以通知對面對應的stream不要再傳資料 畢竟我們的最上層是TCP 如果不通知的話 有這種可能: A端的ID 1拼命傳資料(ex: 上傳測試) B端對應的stream無法達到那麼快的速度 於是A端的ID 1會傳到整個session的token用完(TCP還能寫入就會不斷丟) 造成其他stream一起卡住...

那我這個設計只是加入一個通知的功能 當B端對應的stream無法達到那麼快的速度 會卡住A端的寫入 這麼一來session的token就不會被用完 也就不會造成其他stream一起卡住的問題

是的 理論上是能解決原本issue 至於這個"限速"的後遺症倒是還好 畢竟就是因為太慢才會觸發這個機制

ok 先吃個飯 晚點測試其他的方法 一邊跑youtube一邊跑測速行嗎? 有沒有好一點的測試方法可以建議呢?

[xtaci]

问题的核心在于，在什么条件下去通知发送方，阈值什么是合理的，16KB是拍脑袋?

为什么不是在 stream buffer 达到整体半窗(MaxReceiveBuffer/2)的时候.

[cs8425]

好的 那我先解釋一下MaxStreamBuffer跟MinStreamBuffer的關係 一個有FIFO buffer的高速系統 一般設計上會用總大小的20%當(快要)空 80%當(快要)滿的時候傳送訊號 這樣不會浪費buffer也不會造成overflow (這類的設計在MCU之類的硬體系統很常見, 有些會選30:70、25:75、10:90之類的) 16KB => 80% 4KB => 20% 當然更進階一點的就是設計一個簡單的估測系統(跟RTT、讀寫速度有關) 預估什麼時候送cmdFUL不會造成overflow也不會剩下太多空間 什麼時候送cmdEMP可以在buffer真的被讀到空之前收到新資料

至於MaxStreamBuffer為何選16KB 我是隨手抓沒錯啦 不過還是有點道理的 假設一個(外部無瓶頸)高寫高讀的情況:

1. 讀取端的速度會被侷限於read的頻率&一次讀取的量
2. Buffer至少要保留write完到下次read的資料量才不會影響寫入速度

然而read/write的頻率是有上限的 我沒搞錯的話 在linux kernel跟Internal kernel timer frequency有關 是1000Hz (編譯kernel的時候能調整), 超過就要丟到kernel的buffer/queue 16KB * 1000Hz = 128Mbps ~= 16MB/s 我想應該沒有多少人的頻寬可以支撐N條速度超過128Mbps的stream吧...? 希望我這樣解釋夠清楚@@

[xtaci]

1. 也就是说16KB是经验值， 但是我说的一半也是有道理的， 在cmdFUL到达发送方的半个RTT时间内，剩下的来自发送方的数据流在这个时间刚好把buffer填满。

2. 这样貌似解决的问题是慢速receiver导致卡住的问题，但没有解决快速sender+receiver抢占带宽的问题。 也就是流之间的QoS balance。这个问题存在根本的复杂性。

[cs8425]

為何我不用選MaxReceiveBuffer / 2 因為用這個數值的話 通知對面暫停的時機太晚 有可能 1.速度不夠, 根本用不到那麼大的buffer, 從頭到尾幾乎都沒觸發 2.只要少量的stream觸發這個機制, 很容易造成整個session卡住

正常來說stream buffer使用量會是一個夠小但是變化頻率高的數值 (buffer只保留write完到下次read的資料量, 大大你可以trace一下session.token跟stream.token的數值變化) 太大的stream buffer(相對於MaxReceiveBuffer)效果反而不好

是解決少數慢速receiver造成卡住的問題沒錯 如果要stream之間的QoS問題 可以在這個基礎上加個map計算&紀錄每個stream的速度 大概這幾個速度要紀錄: 下載方向的讀寫、上傳方向的寫、上傳方向對面的讀(這個比較不準, 靠cmdFUL、cmdEMP回授而已, 可能需要在格式加入精確數值的欄位) 速度超標的就通知對面暫停寫入 自己這邊也可以暫停自己的寫入 詳細的頻寬分配方法/條件就要再思考思考了 可以考慮丟個handler function給上層應用來搞XD

另外我發現我命名好像不是那麼好 stream.markFUL()換成stream.pauseWrite() stream.markEMP()換成stream.resumeWrite() 這樣應該會比較好理解

[xtaci]

修改名字是可以的，另外，这个改动不兼容原来的代码，会造成session.go:273的退出，需要一个开关。

另外 CI 目前还过不了，你需要测试下：

  - go test -coverprofile=coverage.txt -covermode=atomic -bench .

[cs8425]

在config裡面加入一個bool來開關行嗎? 預設要關閉還是開啟? 順便問一下, protocol version通常是什麼時候才會增加/改變?

test的部份我覺得蠻奇怪的 在我電腦上測試是會過的 CI不知道為啥沒過

$ go test -coverprofile=coverage.txt -covermode=atomic -bench .
test -coverprofile=coverage.txt -covermode=atomic -bench .
BenchmarkAcceptClose-2         50000         58236 ns/op
BenchmarkConnSmux-2              100      11094876 ns/op      11.81 MB/s
BenchmarkConnTCP-2             10000        109450 ns/op    1197.54 MB/s
PASS
coverage: 90.5% of statements
ok      _/home/cs8425/code/smux 11.486s

[xtaci]

预设应该同之前的版本保持一致，用法无需改动。

[codecov-io]

Codecov Report

Merging #19 into master will increase coverage by 1.04%. The diff coverage is 94.89%.

@@            Coverage Diff            @@
##           master     #19      +/-   ##
=========================================
+ Coverage   89.06%   90.1%   +1.04%     
=========================================
  Files           4       4              
  Lines         384     475      +91     
=========================================
+ Hits          342     428      +86     
- Misses         37      40       +3     
- Partials        5       7       +2

Impacted Files	Coverage Δ
frame.go	100% <ø> (ø)	:arrow_up:
session.go	89.49% <100%> (+1.23%)	:arrow_up:
mux.go	94.28% <77.77%> (-5.72%)	:arrow_down:
stream.go	89.42% <95.38%> (+2.52%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 2de5471...a72c8d6. Read the comment docs.

[xtaci]

带stream.token

原始

实测对于youtube播放，有明显的速度下降，应该就是stream流控所致。

youtube的视频流会应该会通过阻塞读取（暂停读取）来控制TCP推流速度。但加上stream.token的流控，确实又加了一层 cmdFUL/EMP的时钟，或者说类似于TCP_CORK的效果。

[cs8425]

算是trade off吧 剛連線的時候的確無法迅速提高throughput 有個改法是剛連線的stream buffer給比較大 過了幾秒再調回正常(要幾秒可能要思考一下) 代價是一次開多個連線的時候記憶體使用量會瞬間飆高 等速度穩定之後才會降回去 雖然個人認為youtube播放只要跟的上不卡就行... 大大你覺得呢? 剛開的連線給先給比較大的stream buffer這個設計是否有必要?

[xtaci]

我还是觉得，这个问题有根本的困难，内存总用量和流量平衡不可兼得。 可以继续探讨。

[cs8425]

列一下幾個已知條件/現象:

• 所有stream buffer用量加起來不能超過MaxReceiveBuffer, 否則全部會卡住
• cmdFUL/EMP從發送到實際作用會受RTT影響
• 初始throughput的爬升會受stream buffer大小影響
• throughput穩定之後, stream buffer使用量應該接近0

那我試試看改個這種東西出來: 1.剛連線的stream buffer設為MaxReceiveBuffer/2 (或是除其他數, 儘量大但是不要卡住session) 2.觀察stream buffer使用量, 當前用量開始變小(只在0跟上次最大用量之間跳), 判定為進入穩定 3.進入穩定之後stream buffer重設成某個較小的數值(ex: 16KB) 理論上應該有用....晚點試試... RTT部份還在想要怎估測發送時機比較好

[cs8425]

@xtaci 大大你再試試這個版本 加入了RTT測試(收到cmdNOP回傳cmdACK) 簡單估算cmdFUL、cmdEMP發送時機跟stream buffer應該給多少 用自己嚕的TCP over TCP跑youtube測試, 跟 c6b175f 比, 初始爬升快了不少, 最終速度高了大約25% 但是其他iperf之類的速度測試結果差不多就是了

[cs8425]

重編了kcptun 其他測試參數跟上次一樣 不知道為啥今天比較快@@

重點在throughput變化的部份 原本的smux初期會衝到40Mbps左右, 然後再降回25Mbps左右 c6b175f 是一路慢慢爬到20Mbps左右測試就結束了 31ccec0 衝到25Mbps左右就維持在那個位置 上傳部份可能頻寬不夠大看不太出來

目前版本 31ccec0:

c6b175f:

原本的:

[xtaci]

降速是无论如何也不能接受的，影响的用户量太大了。

[cs8425]

31ccec0 並沒有降速啊 是直接爬到頻寬上限就穩定了 而原本的會超過頻寬上限之後才回歸正常 超過的部份就是靠記憶體再撐 所以 31ccec0 如果要達到一樣的效果 把buffer限制開大一點即可

[xtaci]

我先观察一下

[xtaci]

未来两周会有点忙，后面再回复，暂时没有时间验证这个，告知一下。

[cs8425]

要不要另外編譯一版kcptun 開個issue特別著名一下是測試版 交給大家決定要不要當白老鼠&回報結果? 如果不行也沒關係 就等大大有空摟

[xtaci]

不急，慢慢来，先思考一下。

[xtaci]

抱歉晚回复，前几周工作上的事有点忙。

[xtaci]

我始终觉得:

1. 最大吞吐量
2. stream之间流量平衡（stream饿死）
3. 内存总量一定

这三者最多同时满足两者。

[cs8425]

大致上正確 第3點不是總量一定 應該說 RAM要小於 "最大吞吐量所需的RAM" x "stream數量" 而且3者之間的分配vs效果 愈接近極限 會愈沒有效果 假設最大吞吐量要 32kB / stream 95%的最大吞吐量可能只要 16kB / stream 如果RAM的使用量真的無法妥協 我會偏好降個幾%的最大吞吐量 來換(幾乎)所有stream不會卡住 畢竟...youtube點下去播了幾秒發現這不是想要的 點其他影片連結就整個卡住其實還蠻惱人的@@

[jannson]

@cs8425 有空更新一个最新版本么？感觉你说得有道理，我想测试测试。

[cs8425]

@jannson 我直接merge了xtaci的v1.1.1到我的master 7f8c639 你可以先試試看效果 改的有點亂 要提交PR回這邊的話還要多花點功夫...

[jannson]

非常感谢，一回家就开始测试了，手动 merge 了一波。直观感觉效果挺好的～～～　具体参数还没提供。 看了代码，可惜就是无法无缝兼容旧版本！

对了，go test -race 测试不过。

[cs8425]

感謝提醒 已修正 除了基於net.Pipe()的TestParallel2()加上-race還是不會過 把goroutine dump出來看還是找不到原因 全部都在select狀態...

找到問題點了 好像是net.Pipe()有buffer大小的限制 兩邊同時sendLoop()寫到一半剛好buffer滿了 而對面的recvLoop()又正在傳cmdACK cmdFUL cmdEMP不能清空buffer就會卡住

[cs8425]

懶的慢慢修 我從xtaci的master merge這邊重新提交一份PR好了

[jannson]

感謝提醒 已修正 除了基於net.Pipe()的TestParallel2()加上-race還是不會過 把goroutine dump出來看還是找不到原因 全部都在select狀態...

找到問題點了 好像是net.Pipe()有buffer大小的限制 兩邊同時sendLoop()寫到一半剛好buffer滿了 而對面的recvLoop()又正在傳cmdACK cmdFUL cmdEMP不能清空buffer就會卡住

那天晚上为了这个问题我测试到半夜　１　点，现在修复这个问题了？就是 TestParallel2 测试不过，其它改了是没问题的。