고 대역폭 연결을 위해 (매우) 큰 initcwnd를 설정하면 어떤 단점이 있습니까?

Linux에서 3.5 매개 변수를 사용하여 TCP 매개 변수를 실험하고 있습니다. 기본적으로이 연결과 관련하여 :

서버 : 데이터 센터의 기가비트 업 링크, 다른 데이터 센터에서 테스트 할 때 실제 업 링크 공유로 인한 실제 대역폭은 약 70MB / s입니다.

클라이언트 : 200mbit 파이버에 연결된 기가비트 로컬 LAN. 테스트 파일을 가져 오는 것은 실제로 20MB / s를 달성합니다.

지연 시간 : 약 50ms 왕복.

원격 서버는 10-100mb 범위의 파일에 대한 파일 서버로 사용됩니다. 10의 initcwnd를 사용하면 이러한 파일의 전송 시간이 TCP 느린 시작의 영향을 크게 받아 10mb (최고 속도 : 3.3 MB / s)를로드하는 데 3.5 초가 걸리고 느리게 시작하지만 증가합니다. 최대 속도에 도달하기 전에 완료됩니다. 내 목표는 해당 파일의 최소로드 시간을 조정하는 것입니다 (따라서 가장 높은 원시 처리량 또는 최저 왕복 대기 시간이 아니므로 파일을로드하는 데 걸리는 실제 시간이 줄어들면 두 가지를 모두 기꺼이 희생하십시오)

그래서 나는 간단한 연결을 시도하여 다른 연결과 다른 영향을 무시하고 이상적인 initcwnd가 무엇인지 결정했습니다. 대역폭 지연 제품은 200Mbit / s * 50ms = 10Mbit 또는 1.310.720 바이트입니다. initcwnd가 MSS 단위로 설정되고 MSS가 약 1400 바이트라고 가정하면 다음 설정이 필요합니다. 1.310.720 / 1400 = 936

이 값은 기본값 (Linux의 경우 10 * MSS, Windows의 경우 64kb)과는 매우 다르므로 이와 같이 설정하는 것은 좋지 않습니다. 이와 같이 구성하면 예상되는 단점은 무엇입니까? 예 :

• 동일한 네트워크의 다른 사용자에게 영향을 줍니까?
• 다른 연결에 허용 할 수없는 혼잡을 만들 수 있습니까?
• 경로 어딘가에 플러드 라우터 버퍼?
• 소량의 패킷 손실로 인한 영향이 증가합니까?

이와 같이 구성하면 예상되는 단점은 무엇입니까? 예 :

Will it affect other users of the same network?

initcwnd를 변경하면 다음에 영향을 미칩니다.

• 설정이 변경된 서버 사용자
• 해당 사용자가 설정 변경이 구성된 경로와 일치하면

Could it create unacceptable congestion for other connections?

확실한.

Flood router-buffers somewhere on the path?

관련이 없지만 라우터가 아니라면 더 가까운 문제에 중점을 둡니다.

Increase the impact of small amounts of packet-loss?

물론 할 수 있습니다.

결론은 의도적이든 의도적이지 않은 패킷 손실 비용을 증가 시킨다는 것입니다. 서버는 3 방향 핸드 셰이크 (낮은 투자 (데이터 양)를 위해 상당한 양의 데이터를 출력 할 수 있음)를 완료 할 수있는 사람이라면 누구나 DOS보다 간단합니다.

또한 버스트의 첫 번째 패킷 중 하나가 손실되므로 해당 패킷 묶음을 다시 전송해야 할 가능성이 높아집니다.

나는 당신이 요구하는 것을 완전히 이해하지 못한다고 생각하므로 여기에 응답하려는 시도가 있습니다.

우선, 당신이하려고하는 것은 수신 측이 아닌 송신 측에서만 의미가 있습니다. 즉, 수신자가 아닌 파일 서버를 변경해야합니다. 그것이 당신이하는 일이라고 가정 :

initcwnd를 (예) 10으로 변경하면 10 개의 패킷이 즉시 사라집니다. 그들 모두가 목표에 도달하면 느린 시작 (지수 적 증가)으로 인해 첫 번째 RTT에서 훨씬 더 큰 창으로 끝날 수 있습니다. 그러나 패킷 손실시 cwnd는 절반으로 줄어들고 10 개의 패킷으로 버스트되므로 상당한 양의 재전송이 발생하므로 생각보다 많은 문제가 발생할 수 있습니다.

보다 공격적인 것을 시도하고 다른 인터넷 사용자에게 "무례한"행동을 원한다면 서버 쪽에서 혼잡 제어 알고리즘을 변경할 수 있습니다. 다른 알고리즘은 다른 방식으로 cwnd를 처리합니다. 서버 측 소프트웨어가이 연결마다 변경하지 않는 한 모든 사용자에게 영향을 미치게됩니다 (의심 할 것입니다). 여기서 이점은 패킷 손실 후에도 알고리즘이 적용되는 반면 initcwnd는 큰 역할을하지 않는다는 것입니다.

/ proc / sys / net / ipv4 / tcp_congestion_control은 혼잡 제어 알고리즘을 변경하는 위치입니다.

작은 RTT (50ms) 및 중간 또는 큰 파일의 경우 FITW는 initcwnd가 평균 속도에 큰 영향을 미치지 않아야합니다. 패킷 손실이 없으면 (즉, 지방 파이프) cwnd는 모든 RTT에서 두 배가됩니다. 뚱뚱한 파이프에서 RTT = 50ms를 사용하면 첫 번째 초에 20 개의 RTT를 맞습니다. 즉 initcwnd = 2 인 경우 1 초 후에 cwnd = 2 * 2 ^ 20으로 끝날 것입니다. 핸들 ;-)