الخلاصة

  • تسمح draft-ietf-ccwg-ratelimited-increase-11 بنمو محدود لنافذة الازدحام عندما يقيّد التطبيق أو تحكم المستقبل في التدفق عملية الإرسال، وتربط الحد بأكبر FlightSize مرصود.
  • يضبط maxFS حالة المرسل، لكنه لا يحجز عرض نطاق مستقبلي، ولا يفتح رصيد المستقبل، ولا يثبت استخدام pacing أو وصول الدفعة اللاحقة.

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

لكن المقاطع الستة عشر الأخرى لم تختبر المسار أصلاً.

نشرت مجموعة CCWG في IETF مسودّة draft-ietf-ccwg-ratelimited-increase-11 في 6 سبتمبر لتوحيد سلوك يختلف اليوم بين TCP وQUIC وSCTP وDCCP وCUBIC. بعض المواصفات توقف نمو النافذة عندما لا يستخدمها المرسل كاملة. وسلوكيات أخرى قد تسمح بتضخم cwnd بعيداً عن الحجم الذي مر فعلاً. تقترح المسودّة نمواً ممكناً، ولكن منضبطاً بما تمت ملاحظته.

تعني rate-limited هنا أن المرسل يرسل أقل مما تسمح به قواعد الازدحام. قد لا يملك التطبيق بيانات إضافية، أو قد يحجب المستقبل رصيد الاتصال أو التدفق. عندها يبقى FlightSize—حجم البيانات المرسلة التي لم تُقرّ تراكمياً بعد—أقل من cwnd. لا تعني الحالتان وحدهما وجود ازدحام.

تحتفظ الخوارزمية بـmaxFS، وهو أكبر FlightSize منذ آخر خفض للنافذة. تزيده ملاحظة أكبر، بينما يعيده أي خفض لـcwnd إلى الصفر. يجب ألا تتجاوز الزيادة التالية limit(maxFS)، أي القيمة التي كانت الخوارزمية ستنتجها بعد إقرارات نافذة ناجحة بذلك الحجم. في مثال Slow Start يبلغ السقف 2*maxFS، وفي Congestion Avoidance يصبح maxFS+SMSS.

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

وتقر المسودّة بأن الذاكرة تفقد صلاحيتها. قد يبقى maxFS طويلاً، من دون آلية أخرى لتقليل النافذة، حتى لا يعود ممثلاً للمسار الحالي. لذلك تشير إلى RFC 7661 وCongestion Window Validation. تقيس pipeACK فيه الحجم الذي تم الإقرار به خلال فترة RTT، وتفصل النافذة المتحقق منها حديثاً عن حالة مبنية على قدرة قديمة. كلا القياسين دليل محدود زمنياً، لا حق في السعة القادمة.

هناك ثلاث سلطات منفصلة. التطبيق يقرر وجود البايتات. المستقبل يحدد الرصيد. والتحكم في الازدحام يحدّ ما يمكن حقنه وفق إشارات الشبكة. لا تنشئ cwnd كبيرة طلباً، ولا تلغي ضغط المستقبل، ولا تثبّت المسار أو الطوابير أو policers أو حركة المنافسين.

كما أن pacing ليس نتيجة تلقائية لقيمة النافذة. قد يحتفظ المرسل ببيانات أكثر في الطريق مع توزيع الحزم زمنياً لتجنب دفعة واحدة. لا تمنع المسودّة هذا السلوك، لكنها لا تثبت أن تنفيذاً بعينه فعّله أو اختار فاصلًا آمناً أو منع التجميع الناتج عن offload. يلزم سجل إعداد وملاحظة فعلية للحزم.

ويتحدث ACK عن بيانات سابقة ضمن قواعد بروتوكول محدد. يفيد في الاسترداد من الفقد وتحديث حالة الازدحام، لكنه لا يضمن رصيداً جديداً أو بقاء المسار أو قبول التطبيق للعملية التالية. قد تثبت المصادقة هوية مصدر الإقرار، لكنها لا تمنحه سلطة على المستقبل.

إذا أُقرت المسودّة فستحدّث RFC 4341 و5681 و9002 و9260 و9438. لكنها الآن Internet-Draft قابلة للتغيير ولا تطلب إجراءً من IANA. تقدّم المعيار، وجود الكود، تفعيل الميزة، والنتيجة الإنتاجية أربعة سجلات مستقلة.

المصادر