الخلاصة

  • في draft-xiao-fann-fast-cnp-with-proxy-05 ترسل العقدة المزدحمة إشعار UDP أولاً إلى وكيل، ثم يعيد الوكيل بناء حزمة ثانية يفهمها مرسل RoCEv2.
  • قد تكون حزمة CNP التي تصل إلى المرسل صحيحة ومفيدة، لكنها لا تكشف إصدار خريطة التدفق وQP، ولا هوية عقدة الازدحام الأصلية، ولا عدد الإشعارات التي أسقطها الوكيل وفق سياسته المحلية.

يرى المرسل حزمة RoCEv2 Congestion Notification Packet قياسية فيخفض معدل Queue Pair المتأثر. تبدو الإشارة مألوفة من جهته. لكن الموجّه المزدحم لم يرسل إليه تلك الحزمة مباشرة. فقد أرسل رسالة UDP مختلفة إلى وكيل، واستخرج الوكيل من حالة تعلّمها من حركة المرور هوية المرسل وSource QP، ثم أنشأ الحزمة التي وصلت إلى المضيف.

هذا التحويل هو جوهر المراجعة 05 من Fast Congestion Notification Packet with Proxy المنشورة في 29 سبتمبر. قد يعمل موجّه مزود VPN في نطاق توجيه غير نطاق المرسل، وقد لا يملك معلومات Source QP اللازمة لبناء CNP التقليدية. يصل الوكيل بين السياقين.

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

حدث واحد يتحول إلى حزمتين

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

تحمل الصيغة الأولى الخماسية IP لتدفق البيانات وDestination QP بطول 24 بت إلى منفذ UDP المقترح TBD1. يستخدم الوكيل عنوان المصدر لتحديد المرسل، ويستدل من البروتوكول ومنفذ الوجهة على RoCEv2. لكنه يحتاج إلى Source QP لإنشاء CNP القياسية، فيستخرجه من خريطة Source-QP/Destination-QP محفوظة ضمن سياق عنواني المصدر والوجهة.

هذه الخريطة ليست مجرد إعداد ثابت. يجب أن يكون الوكيل المختار على مسار حركة RoCEv2 في الاتجاهين كي يتعلم الارتباط. تحمل رسالة الازدحام Destination QP ولا تحمل Source QP جاهزاً. لذلك يعتمد التحويل على حالة رصد احتُفظ بها من مرور سابق.

أما الصيغة الثانية فتحمل الخماسية وNRP Selector ID إلى منفذ مقترح آخر هو TBD2. في حالة RoCEv2 يساعد المحدد على معرفة Source QP، وفي حالة VPN يساعد على معرفة الشبكة الافتراضية. يحتاج الوكيل هنا إلى خرائط Source-QP/NRP أو VPN-ID/NRP. المحدد مفتاح بحث، وليس برهاناً على أن الجدول ما زال حديثاً.

إعلان القدرة لا يثبت جهوزية التحويل

تحتاج عقدة الازدحام أولاً إلى معرفة الوكيل الذي يخدم بادئة المرسل. يقترح المستند إعلان Proxy Node Capability، أو PNC، مع البوادئ المتصلة بالمرسلين. تستخدم IS-IS وOSPF أعلام P مقترحة، ويستخدم BGP بنية Next Hop Dependent Characteristic TLV مقترحة تحمل عنوان الوكيل.

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

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

قد يسقط الوكيل الأدلة عمداً

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

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

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

ويصبح الصمت متعدد المعاني: ربما لم يقع ازدحام، أو اختير وكيل خاطئ، أو كانت مسارات PNC قديمة، أو فشلت الخريطة، أو تدخل مرشح حدودي، أو بقيت الوظيفة معطلة، أو طبق الوكيل حد المعدل، أو ضاعت الحزمة الثانية. صيغة السلك لا تفصل بين هذه الحالات.

حزمة CNP المفيدة ليست إيصال منشأ

لا يعني ذلك أن التعليمات المترجمة كاذبة. فقد تحمل بالضبط ما يحتاجه المرسل القديم: خفض معدل Source QP الذي أعاد الوكيل بناءه. وتأتي قيمتها من عدم اضطرار الطرف النهائي إلى فهم الصيغة الجديدة.

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

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

لا يقدم سجل واحد هذه الصورة. القيمة في الربط بينها.

المراجعة 05 تضيق ادعاء النضج أيضاً

تحذف المراجعة الجديدة لغة أوسع عن مرسلين لا يستخدمون RoCE، وتوضح مسار بناء CNP القياسية في RoCEv2. كما تنص صراحة على أن تعلم علاقة Source-QP/Destination-QP يتطلب وجود الوكيل على مساري الذهاب والعودة. وتشير إلى أن بعض التطبيقات قد تستخدم حزمة بيانات تحمل علامة ECN كمدخل إلى الوكيل، لكنها تترك هذه الطريقة خارج النطاق.

هذه الإشارة ليست صيغة ثالثة محددة ولا تقرير توافق بين تطبيقات. يظل المستند مسودة إنترنت فردية بلا stream أو AD مسؤول أو موقف رسمي من IETF. المنافذ وأعلام التوجيه ورمز خاصية BGP كلها مقترحات. لا تثبت الحزمة المحددة وجود نشر فعلي أو أداء مقاس أو تطبيق متوافق مسمى.

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

المصادر