الخلاصة

  • أضافت المراجعة المؤرخة في 2 أكتوبر لمسودة مفاهيم SIMAP التابعة لفريق NMOP مطلب REQ-CONGESTION: ينبغي ألا تتسبب حركة ربط بروتوكول SIMAP في ازدحام مستمر. لم تتضمن المراجعة 13 هذا المطلب المسمّى.
  • يعد النص النقل المزود بضبط ازدحام، مثل الربط القائم على TCP، مستوفياً لهذا الجانب. أما الربط الذي يفتقر إلى هذا الضبط، مع ذكر UDP مثالاً، فيُحصر في بيئة محكومة بسعة مهيأة مسبقاً أو محجوزة، ويُفرض حد على ما يولده الخادم من حركة. هذه مسودة إنترنت نشطة وليست معياراً معتمداً.

قد تكون الخريطة دقيقة في عرض الشبكة، ومع ذلك تستهلك من مواردها أكثر مما ينبغي. وكلما زادت وتيرة طلب حالة الوصلات وتحديث الطوبولوجيا وإرسال الإشعارات إلى المشتركين، زاد الحمل الذي تصنعه وسيلة الرصد. بهذا المعنى لا يكفي السؤال عما إذا كانت البيانات حديثة؛ يجب السؤال أيضاً عن كلفة الحصول عليها. المراجعة 14 من وثيقة Service & Infrastructure Maps، أو SIMAP، تنقل هذه الكلفة إلى صلب متطلبات التصميم المقترح.

في القسم 4.3 من draft-ietf-nmop-simap-concept-14 أُدرج REQ-CONGESTION ليشترط ألا تسبب حركة SIMAP ازدحاماً مستمراً. تكشف المقارنة مع النسخة 13 أن النص إضافة محددة، لا مجرد تسمية جديدة لبند الأداء. وتقول المسودة إن طبقة نقل تضبط الازدحام، ومنها الربط المبني على TCP، تحقق هذا الشرط على مستوى النقل. وإذا غاب هذا الضبط، كما في المثال القائم على UDP، فلا بد من حصر الاستخدام في بيئة خاضعة للسيطرة ذات سعة محجوزة أو معدة سلفاً، مع تقييد حجم الحركة التي يمكن أن يصدرها الخادم.

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

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

وتحيل الفقرة الجديدة إلى RFC 8085، وهي إرشادات سابقة توضح أن UDP لا يقدم ضبط ازدحام بطبيعته، وأن التطبيق مسؤول عن اتخاذ التدابير المناسبة. ليست تلك الوثيقة إصداراً جديداً هذا الأسبوع، ولا دليلاً على إخفاق SIMAP في الإنتاج. كما أن سجل IETF ما زال يصف SIMAP بمسودة لفريق عمل يراد لها أن تكون معلوماتية، وهي في انتظار متابعة من مدير المجال؛ لا يصح وصفها بأنها RFC صودق عليها.

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

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

المصادر