الخلاصة

  • تخفّض RFC 3742 زيادة نافذة TCP بعد تجاوز cwnd للعتبة max_ssthresh، لأن البدء الأسي قد يضيف آلاف المقاطع في دورة RTT واحدة.
  • صحّح Erratum 236 المعتمد نطاق الزيادة لكل RTT: فالوصول إلى 83 ألف حزمة يستغرق في المثال 836 دورة على الأقل، لا هذا العدد بالضبط.

لا تعني كلمة «محدود» أن الإرسال صار بمعدل ثابت. كانت RFC 3742 مقترحاً تجريبياً اختيارياً صدر عام 2004 لاتصالات TCP ذات نوافذ ازدحام قد تبلغ آلاف وحدات حجم المقطع الأقصى. عند cwnd <= max_ssthresh أبقت القاعدة على زيادة MSS واحدة مع كل ACK وارد. وبعد تجاوز العتبة تحسب K = int(cwnd / (0.5 * max_ssthresh))، ثم تضيف نحو 1/K من MSS لكل ACK. ولا تحل max_ssthresh محل ssthresh؛ فتجاوز العتبة الثانية يظل نهاية مرحلة البدء البطيء.

بدت صياغة القسم الثاني من RFC أكثر حسماً مما تسمح به القاعدة. قال النص الأصلي إن الزيادة بعد max_ssthresh لا تتجاوز نصف قيمة العتبة في كل RTT، لكن القاعدة التي تُطبّق مع كل ACK، ويتغير فيها K على مراحل، تعطي نطاقاً. صحّح Erratum 236، الذي اعتمده محررو RFC، الثابتَ إلى حد أقصى قدره max_ssthresh من وحدات MSS لكل RTT وحد أدنى يساوي نصفه. كما استبدل معادلة زمن واحدة بحدين أدنى وأعلى. وفي مثال العتبة البالغة 100 MSS والهدف البالغ 83 ألف حزمة، صارت مدة 836 RTT التي يُستشهد بها كثيراً تعني «836 على الأقل».

هذا تصويب لوصف الآلية، لا خوارزمية جديدة للتحكم في الازدحام. بقي نص RFC المنشور عام 2004 كما هو؛ والتصويب سجل مستقل ينبغي قراءته إلى جانبه. وهو يوسّع نطاق النمو والمدة الممكنين في التفسير، لكنه لا يحوّل أياً من طرفي النطاق إلى نتيجة مقاسة تنطبق على الجميع.

كان الحد يستهدف أثر الزيادة في المرسل وفي الشبكة معاً. فقد تؤدي قفزة كبيرة أثناء البدء البطيء إلى خسائر كثيرة دفعة واحدة، وانتهاء مهلة إعادة الإرسال، ثم هبوط نافذة الاتصال إلى قيمة صغيرة. كما تتأثر تدفقات أخرى تتشارك عنق الزجاجة بالصفوف والخسائر. أوردت RFC 3742 مثالاً بعتبة 100 MSS، وذكرت تجارب أولية على نواة Linux 2.4.16 Web100. هذا سجل تاريخي محدود، وليس دليلاً على انتشار الآلية اليوم أو نفعها في الإنترنت كله أو ضمانها حجماً معيناً للطابور.

استخدمت وثائق TCP اللاحقة إشارات تحكم مختلفة. توصي RFC 9438 عادةً باستخدام HyStart++ في البدء البطيء لخوارزمية CUBIC، وتذكر Limited Slow-Start بوصفها خياراً تجريبياً. أما RFC 9406 فتستخدم ارتفاع RTT كإشارة محتملة للخروج من البدء البطيء، ثم تضيف مرحلة متحفظة للتحقق من أن الخروج لم يكن مبكراً. وهذه إشارة مختلفة عن الزيادة لكل ACK المرتبطة بحجم النافذة في RFC 3742؛ فلا ينبغي الخلط بين الآليتين.

بالنسبة إلى مشغلي الشبكات، يذكّر التصويب بضرورة السؤال عمّا يحدّه الرقم البارز فعلاً. فزيادة النافذة لكل RTT ليست سقفاً مباشراً لمعدل البايتات، ولا قياساً للطابور، ولا برهاناً على الإنصاف في مسار مشترك. تتحدد النتيجة بتفاعل العتبة وACK والتوقيت الموزع والتخزين المؤقت وRTT والتدفقات المنافسة. يجعل التصويب عدم اليقين في RFC أوضح، لكنه لا يزيله.

المصادر