TCP 흐름 설정에서 최대 처리량과 최소 대기 시간을 얻기 위해 다양한 혼잡 제어 알고리즘을 시도하고 있습니다. 다음 외에 사용 가능한 다른 알고리즘을 제안해 주세요.
비노, 웨스트우드, 리노, 큐브
구현(또는 커널 모듈)은 인터넷에서 무료로 사용할 수 있습니다. 그리고 더 높은 처리량을 얻기 위해 서로 다른 측면에서 Linux(Fedora)와 Windows 7 TCP 스택 간에 TCP를 실행하는 다른 방법이 있는지 제안해 보세요.
답변1
블랙 박스 :).
패킷 손실률이 15% 미만이면 BBR은 경로를 완전히 활용할 수 있습니다.(link_bandwidth*(1 - loss_rate)에 도달). 이 15% 임계값은 기본 한계가 아닌 설계 매개변수입니다.
이것이 무엇을 의미하는지 정확하게 설명하려고 합니다. 저는 에릭 듀마셋입니다:
큐빅과 비교하면 손실이 있는 환경에서는 2~4배의 차이가 있습니다.
100ms rtt 및 1% 패킷 손실의 예. 큐빅은 거기에서 끔찍했습니다.
$ netperf -H 10.246.7.152 -l 30 -- -K cubic
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 40.00 3.27
$ netperf -H 10.246.7.152 -l 30 -- -K bbr
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.25 9150.01
타사 테스트에서는 경합이 있는 경우 현재 코드가 병목 현상 시 전체 버퍼(BDP)를 예상한다는 설명을 공개/제안했습니다. 이는 추가 개선이 필요한 것으로 알려진 목표입니다. 조건이 충족되지 않으면 손실률이 높아집니다. 그러면 전통적인 TCP는 기본적으로 굶어 죽을 것입니다.
만약 있다면더1 BDP보다 큰 버퍼, BBR 스트림은 과도한 버퍼를 채우지 않도록 협력하므로요구 사항에 따라 대기열 지연을 제한하세요.. 기존 TCP는 전체 버퍼를 채우는 경향이 있습니다. BBR은 두 가지가 경쟁할 때 레거시 TCP 스트림의 동작을 마술처럼 고칠 수는 없지만 이것이 다른 방식으로 BBR에 해를 끼치지는 않는다고 생각합니다.
위의 조건이 충족되지 않으면 애플리케이션 대기 시간에 영향을 미칩니다(손실된 패킷을 다시 전송해야 함).
https://groups.google.com/forum/#!forum/bbr-dev
답변2
무자비한 TCP는 당신이 얻을 수 있는 가장 무자비한 TCP가 될 것입니다.