الخلاصة

  • يجعل RFC 9937 خوارزمية PRR قاعدة Standards Track لتنظيم كمية ما يرسله طرف TCP أثناء الاسترداد السريع، نحو هدف ssthresh الذي يحدده متحكم الازدحام.
  • قيمة SndCnt الناتجة عن ACK وتقديرات المرسل لا تثبت أن المسار كله خالٍ، أو أن التطبيق المستقبِل أنهى العمل، أو أن وعد الخدمة تحقق.

حين تعود ACKs بعد فقد، قد تتحول عبارة «يمكن الإرسال مجدداً» إلى «تعافت الشبكة». هذه قفزة من حساب طرف واحد إلى حكم على واقع مشترك. RFC 9937 لا يطلب تلك القفزة. فهو وثيقة IETF Standards Track من ديسمبر 2025 تحل محل RFC 6937، وتعرّف Proportional Rate Reduction لتنظيم البيانات المرسلة في الاسترداد السريع بحيث يقترب flight size الفعلي من ssthresh.

تلك العتبة يختارها متحكم الازدحام؛ PRR لا تمنحها معنى تجارياً ولا تحجزها من تدفقات أخرى. يحتفظ المرسل بأفضل تقديراته لـ DeliveredData وinflight وRecoverFS. ومع SafeACK والعدادات يستخرج SndCnt، أي عدد البايتات التي يرسلها استجابة لذلك ACK. فوق العتبة يكون التنظيم تناسبياً؛ وتحتها توجد قيد محافظ، مع سماح محدود إذا دل ACK على تقدم جيد. وفي نهاية الحلقة تضبط الخوارزمية cwnd إلى ssthresh، بينما يوصي RFC بـ pacing لأن ذلك قد يسمح بدفعة متتالية.

هذه ليست صورة كاملة للمسار. SACK يزيد الدقة لكنه ليس شرطاً، ويمكن لخوارزميات كشف فقد مختلفة أن تزود PRR بالمدخلات. وفي حالة غياب SACK يحد النص من أثر ACKs المكررة غير السليمة التي قد تضخم تقدير التسليم. أي إن الحساب قد يكون مضبوطاً تماماً في نطاقه، ومع ذلك لا يعرف طابور مزود آخر أو سياسة شرطي مرور أو نتيجة التطبيق البعيد.

النشر التدريجي يغير تطبيق النقل لدى المرسل ولا يتطلب تغيير المستقبل أو الشبكة. يمكن استخدام PRR مع Reno أو CUBIC، لكن العدالة يحددها متحكم الازدحام. لا يملك مجدول الإرسال بهذا سلطة إعلان مورد مشترك متاحاً.

الوثيقة التشغيلية المناسبة هي إيصال استرداد: المتحكم وإصداره، ssthresh، ACK/SACK ومدخلات كشف الفقد، التقديرات، SndCnt، الإرسال المعاد وpacing، حدود نافذة الاستقبال والتطبيق، ثم مشاهدة مستقلة لما حدث بعد ذلك. أولوية الكود العامل لدى Heng Lu تحمي هذه الحدود: يثبت الكود ما حسبه ونفذه، لا ما لم يرصده في العالم كله.

المصادر