RFC 3124: لم يكن إذن الإرسال طابور حزم

الخلاصة

كانت cm_request تعلن أن لدى التطبيق بيانات يرغب في إرسالها من دون تسليم مخزن بيانات إلى مدير الازدحام؛ وكانت cmapp_send تمنحه كمية محدودة، غالبًا حتى PMTU، ولزمن قصير.
لم تثبت المنحة وجود حزمة في طابور ولا وصولها. يختار التطبيق المحتوى أو يعيد تقسيمه، ثم يبلغ البايتات الخارجة فعليًا عبر cm_notify، ويقدم معلومات المستقبِل بصورة منفصلة عبر cm_update.

ازدحام واحد وذاكرات كثيرة داخل الجهاز

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

ناقشت RFC 2140 مشاركة بعض حالة TCP بين اتصالات زوج من الأجهزة. أما RFC 3124، المنشورة ضمن مسار المعايير في يونيو 2001، فاقترحت خدمة أوسع في النظام الطرفي. يجمع Congestion Manager، أو CM، التدفقات في macroflow، ويشارك حالة الازدحام وخوارزمياته، ويعرض واجهة لتطبيقات لا يلزم أن تكون TCP.

لم يكن الهدف جمع كل البيانات في طابور مركزي. عالج التصميم سؤالين منفصلين: متى تسمح حالة الازدحام بالإرسال، وما المحتوى الذي يستحق تلك الفرصة؟ يعرف المدير الطلبات المتنافسة، ويعرف التطبيق قيمة الإطار أو الرسالة في لحظتها.

الطلب لم يحمل مخزن البيانات

عند استدعاء cm_request، كان التطبيق يعلن الحاجة فقط. لم يسلّم buffer يحتفظ به CM، ولذلك لم يكن المدير يخزن payload أو يعد بإرسال رسالة معينة لاحقًا.

حين يسمح المتحكم والجدولة، يستدعي CM الدالة cmapp_send. تحدد المنحة حدًا أعلى، عادة بقدر path MTU. عندها يختار التطبيق البيانات. يستطيع برنامج فيديو إسقاط إطار قديم، أو خفض الجودة، أو إعادة التقسيم كي يلائم المساحة المتاحة.

تتيح هذه اللحظة المتأخرة لكل طرف استخدام معرفته. يرى CM النافذة والطلبات، بينما يفهم التطبيق معنى بياناته وحداثتها. يلتقي مستويا التحكم والبيانات في الإذن من دون أن يستولي أحدهما على وظيفة الآخر.

لذلك لا يعد callback إيصال إرسال. بعده تبقى صناعة الحزمة وتسليمها إلى IP وخروجها من الواجهة. قد لا يستخدم التطبيق الفرصة، أو قد تكون قد انتهت عند التنفيذ.

المنحة تنتهي وتحتاج إلى تسوية

حدد المعيار صلاحية الفرصة بالحد الأكبر بين RTT وعتبة تختارها عملية التنفيذ. لا يجوز استخدام callback منتهي الصلاحية. فالحالة التي بررت المنحة تتغير، ولا يمكن ادخارها كرصيد دائم.

بعد المحاولة يستدعي التطبيق cm_notify(nsent) ليذكر عدد البايتات الموضوعة فعليًا عند IP output. وإذا لم يرسل شيئًا فعليه الإبلاغ بصفر وإعادة الفرصة. هكذا تصبح الحاجة والمنحة والاستخدام أحداثًا مستقلة في الحساب.

توقع التصميم أيضًا تعطل التطبيق قبل إخطار الصفر. يجب أن يتعافى CM كي لا يحبس الطلبات الأخرى. لكن تحمل الخطأ لا يعني تسجيل كل منحة بوصفها إرسالًا خياليًا.

تعني nsent ما أخرجه الجهاز، لا ما تلقاه الطرف الآخر. تأتي أدلة المستقبِل عبر cm_update، مع التمييز بين الاستلام والخسارة وإشارة الازدحام وغياب التغذية الراجعة. كانت المنحة والفعل المحلي والملاحظة البعيدة سجلات مختلفة.

كان macroflow فرضية تشغيلية

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

ينبغي حفظ مفتاح macroflow مع المسار والواجهة والوجهة والقياس في الوقت نفسه. ومن دون ذلك، لا يثبت المعرّف سوى قرار محلي اتخذه البرنامج، ولا يثبت حقيقة الطريق.

تشرح RFC 2581 وRFC 2861 ثم RFC 5681 جوانب من سلوك TCP، وعادت RFC 9040 إلى مقاييس النقل المشتركة. لكن خصوصية RFC 3124 كانت بروتوكول الطلب والمنحة والإخطار الموجه إلى التطبيق، مع جدولة مشتركة، لا مجرد ذاكرة لمقاييس TCP.

«حسن السلوك» كان عقد تعاون

سمى النص التطبيق حسن السلوك عندما لا يرسل إلا بموافقة CM ويبلغ كل البيانات المرسلة بدقة. كان ذلك التزامًا على المشارك، لا حاجزًا تقنيًا يمنع كل عملية في الجهاز.

أكدت RFC أن CM لا يفرض السلوك على جميع التطبيقات ولا يحمي الشبكة من جهاز مخترق. يحتاج policing في الجهاز أو الموجّه إلى آلية أخرى خارج النطاق. يستطيع برنامج خبيث أو غير مشارك تجاوز الواجهة.

لذلك لا يثبت وجود الوحدة أن كل حركة الجهاز خضعت لها. ولا تثبت استدعاءات تطبيق واحد غياب حركة موازية تجاوزتها. وحتى التسلسل الصحيح لا يثبت أن الحزم اتبعت المسار الذي افترضه macroflow.

كان التبني اختياريًا. من يختار الخدمة يجب أن يتبع مواصفاتها، لكن تصنيف Standards Track لا يقدم دليلًا على الانتشار أو النجاح التشغيلي.

بقي المجهول مختلفًا عن الصفر

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

الجهل والقياس الصفري يقودان إلى قرارين مختلفين. وينطبق الانضباط نفسه على التاريخ: غياب دليل النشر ليس دليل فشل، ووجود المعيار ليس دليل تبن. توفر RFC 2914 مبادئ الازدحام، وRFC 2481 سياق ECN، وRFC 1191 سياق PMTU، وتوضح RFC 8085 مسؤوليات UDP اللاحقة. لا تثبت أي منها تشغيل RFC 3124 في منتج بعينه.

الإرسال الكامل يحتاج إلى عدة إيصالات

يبدأ السجل القابل للتدقيق بوقت cm_request وهوية التدفق وmacroflow وحالة الجدولة. ثم يحفظ زمن callback وحده وPMTU وRTT وحساب الانتهاء، والمحتوى المختار، وcm_notify عند خروج IP، والواجهة والمسار وكل cm_update. أما النتيجة المرئية للمستخدم فتحتاج إلى قياسات أخرى.

يثبت الطلب حاجة معلنة، وتثبت المنحة فرصة مؤقتة، ويثبت الإخطار الإيجابي تقريرًا محليًا عن الإرسال، وتصف تغذية المستقبِل جزءًا لاحقًا من الرحلة. لا يجوز أن يحل سجل واحد محل السلسلة كلها.

تكمن قيمة RFC 3124 في هذا الفصل. فقد شاركت معرفة الازدحام من دون نقل ملكية البيانات إلى المتحكم. كان إذن الإرسال قرار توقيت، لا الحزمة ولا وصولها.

لم يكن إذن الإرسال طابور حزم: RFC 3124

لماذا هذا مهم

الخلاصة

ازدحام واحد وذاكرات كثيرة داخل الجهاز

الطلب لم يحمل مخزن البيانات

المنحة تنتهي وتحتاج إلى تسوية

كان macroflow فرضية تشغيلية

«حسن السلوك» كان عقد تعاون

بقي المجهول مختلفًا عن الصفر

الإرسال الكامل يحتاج إلى عدة إيصالات

المصادر

سياق أعمق للملف الشخصي

الدائرة الاستراتيجية

تحالف القيادات

إحاطة الدائرة الاستراتيجية

إحاطة تحالف القيادات