สิ่งที่เป็นไปได้ในการตั้งค่าขนาดใหญ่ (มาก) initcwnd สำหรับการเชื่อมต่อแบนด์วิดธ์สูง?

ฉันได้ทดลองกับพารามิเตอร์ TCP ใน Linux (ด้วยเคอร์เนล 3.5) โดยทั่วไปเกี่ยวกับการเชื่อมต่อนี้:

เซิร์ฟเวอร์: Gigabit อัปลิงค์ในดาต้าเซ็นเตอร์แบนด์วิดท์จริง (เนื่องจากการแบ่งปันอัปลิงค์) ประมาณ 70 MB / s เมื่อทดสอบจากดาต้าเซ็นเตอร์อื่น

ไคลเอนต์: กิกะบิตท้องถิ่น LAN เชื่อมต่อกับไฟเบอร์ 200mbit การดึงไฟล์ทดสอบมาถึง 20 MB / s

Latency: ประมาณ 50ms ไปกลับ

รีโมตเซิร์ฟเวอร์ใช้เป็นเซิร์ฟเวอร์ไฟล์สำหรับไฟล์ในช่วง 10 ถึง 100mb ฉันสังเกตเห็นว่าการใช้ initcwnd จาก 10 เวลาในการถ่ายโอนไฟล์เหล่านี้ได้รับผลกระทบอย่างมากจาก TCP ช้าเริ่มต้นใช้เวลา 3.5 วินาทีในการโหลด 10mb (ความเร็วสูงสุดถึง: 3.3 MB / s) เพราะมันเริ่มช้าแล้วก็ลาดขึ้น เสร็จสิ้นก่อนที่จะถึงความเร็วสูงสุด เป้าหมายของฉันคือการปรับแต่งเวลาในการโหลดไฟล์เหล่านั้นให้น้อยที่สุด (ดังนั้นจึงไม่ผ่านทราฟฟิกสูงสุดหรือเวลาแฝงไปกลับต่ำที่สุดฉันยินดีที่จะเสียสละทั้งสองอย่างถ้ามันลดเวลาที่ใช้จริงในการโหลดไฟล์)

ดังนั้นฉันจึงลองคำนวณง่าย ๆ เพื่อกำหนดว่าอะไรคือสิ่งที่ดีที่สุดที่ควรจะเป็นโดยไม่สนใจการเชื่อมต่ออื่น ๆ และผลกระทบที่อาจเกิดขึ้นกับผู้อื่น แบนด์วิดท์ล่าช้าของผลิตภัณฑ์คือ 200 Mbit / s * 50ms = 10 Mbit หรือ 1.310.720 ไบต์ พิจารณาว่า initcwnd ตั้งอยู่ในหน่วยของ MSS และสมมติว่า MSS อยู่ที่ประมาณ 1,400 ไบต์ซึ่งจะต้องมีการตั้งค่า: 1.310.720 / 1400 = 936

ค่านี้อยู่ไกลจากค่าเริ่มต้น (10 * MSS ใน Linux, 64kb ใน Windows) ดังนั้นจึงไม่ควรตั้งค่าเช่นนี้ ข้อเสียที่คาดหวังของการกำหนดค่าเช่นนี้คืออะไร? เช่น:

• จะส่งผลกระทบต่อผู้ใช้รายอื่นในเครือข่ายเดียวกันหรือไม่
• มันสามารถสร้างความแออัดที่ยอมรับไม่ได้สำหรับการเชื่อมต่ออื่น ๆ หรือไม่?
• ท่วมเราเตอร์บัฟเฟอร์ที่ใดที่หนึ่งบนเส้นทางหรือไม่
• เพิ่มผลกระทบของการสูญเสียแพ็กเก็ตจำนวนเล็กน้อยหรือไม่

ข้อเสียที่คาดหวังของการกำหนดค่าเช่นนี้คืออะไร? เช่น:

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?

แน่นอนว่าสามารถทำได้

ผลที่สุดคือการเพิ่มค่าใช้จ่ายของการสูญเสียแพ็กเก็ตทั้งโดยเจตนาและไม่ตั้งใจ เซิร์ฟเวอร์ของคุณนั้นง่ายกว่าสำหรับ DOS โดยทุกคนที่มีความสามารถในการจับมือ 3 ทาง (ข้อมูลจำนวนมากออกมาเพื่อการลงทุนต่ำ (จำนวนข้อมูล))

นอกจากนี้ยังจะเพิ่มโอกาสที่กลุ่มของแพ็กเก็ตเหล่านั้นจะต้องถูกส่งใหม่เพราะหนึ่งในแพ็กเก็ตแรกที่ระเบิดจะหายไป

ฉันไม่คิดว่าฉันเข้าใจอย่างถ่องแท้ถึงสิ่งที่คุณต้องการดังนั้นนี่เป็นความพยายามที่จะตอบกลับ:

ก่อนอื่นสิ่งที่คุณพยายามทำมีเพียงแค่ความรู้สึกในด้านการส่งไม่ใช่ด้านที่รับ คือคุณต้องเปลี่ยนไฟล์เซิร์ฟเวอร์ไม่ใช่ผู้รับ สมมติว่าเป็นสิ่งที่คุณทำ:

การเปลี่ยน initcwnd เป็น (เช่น) 10 หมายความว่า 10 แพ็กเก็ตจะหายไปทันที หากพวกเขาทั้งหมดไปถึงเป้าหมายของพวกเขาคุณอาจท้ายด้วยหน้าต่างที่มีขนาดใหญ่กว่ามากใน RTT แรกเนื่องจากการเริ่มต้นช้า (การเพิ่มแบบทวีคูณเพิ่มขึ้น) อย่างไรก็ตามเมื่อสูญเสียแพ็คเก็ต cwnd จะถูกลดลงครึ่งหนึ่งและเมื่อคุณระเบิดด้วย 10 แพ็คเก็ตคุณจะมีจำนวนการส่งสัญญาณซ้ำจำนวนมากดังนั้นคุณอาจพบปัญหามากกว่าที่คุณคิด

หากคุณต้องการลองสิ่งที่ก้าวร้าวมากขึ้นและ "หยาบคาย" กับผู้ใช้อินเทอร์เน็ตรายอื่นมากกว่าที่คุณสามารถเปลี่ยนอัลกอริทึมการควบคุมความแออัดที่ด้านเซิร์ฟเวอร์แทน อัลกอริทึมที่แตกต่างกันจัดการ cwnd ในวิธีที่แตกต่าง โปรดทราบว่าการดำเนินการนี้จะส่งผลกระทบต่อผู้ใช้ทุกคนยกเว้นว่าซอฟต์แวร์ฝั่งเซิร์ฟเวอร์ของคุณจะเปลี่ยนการเชื่อมต่อนี้ (ซึ่งฉันสงสัยอย่างมาก) ประโยชน์ที่นี่คืออัลกอริทึมจะมีผลแม้หลังจากการสูญหายของแพ็กเก็ตในขณะที่ initcwnd จะไม่เล่นบทบาทมาก

/ proc / sys / net / ipv4 / tcp_congestion_control เป็นที่ที่คุณเปลี่ยนอัลกอริทึมการควบคุมความแออัด

FWIW สำหรับ RTT ขนาดเล็กเช่น (50ms) และสำหรับไฟล์ขนาดกลางหรือขนาดใหญ่ initcwnd ไม่ควรส่งผลกระทบต่อความเร็วเฉลี่ยของคุณมากนัก หากไม่มีการสูญเสียแพ็คเก็ต (เช่นท่อไขมัน) cwnd จะเพิ่มเป็นสองเท่าในทุก RTT ด้วย RTT = 50ms ในท่อไขมันคุณจะพอดีกับ 20 RTT ในวินาทีแรกซึ่งหมายความว่าด้วย initcwnd = 2 คุณจะจบลงด้วย cwnd = 2 * 2 ^ 20 หลังจาก 1 วินาทีซึ่งฉันเดิมพันได้มากกว่าที่คุณสามารถ ด้ามจับ ;-)