الخلاصة

  • اشترت IntServ الدقة بحالة لكل تدفق، بينما اشترت DiffServ قابلية التوسع بتجميع التدفقات وتقليل ما يعرفه القلب.
  • حددت RFC 2990 إشارتين غير معرفتين: توافر الموارد من القلب إلى الحافة، ونتيجة القبول من الحافة إلى التطبيق.
  • لا يصبح المستوى الممتاز وعدًا قابلًا للتحقق إلا إذا بقي الاكتشاف والقبول والقياس ونسبة الاستخدام مراحل مستقلة ذات أدلة.

خدمة بلا جواب سلبي

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

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

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

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

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

حدود ترى السياسة ولا ترى السعة كلها

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

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

لهذا احتاجت الحلقة إلى مرحلتين منفصلتين:

  1. من القلب إلى الحافة: ما المورد المتاح الآن، وإلى متى تبقى المعلومة صالحة؟
  2. من الحافة إلى التطبيق: هل قُبل الطلب، أم خُفض، أم رُفض؟

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

اكتشاف المسار قبل حجزه

افترض IntServ وDiffServ غالبًا استخدام المسار الذي اختاره توجيه أفضل جهد. في نشر غير متجانس قد يدعم مسار ما خدمة معينة بينما لا يدعمها مسار آخر. المسار الأقل كلفة وفق مقياس التوجيه ليس بالضرورة المسار القادر على أداء الخدمة.

لاحظت RFC 2990 غياب طريقة قوية تسمح للتطبيق بالسؤال عن عدة مسارات مرشحة. علامة الحزمة تطلب معاملة على مسار قائم؛ لا تكتشف بديلًا. والحجز على المسار المختار لا يثبت أنه الخيار الوحيد أو الأفضل.

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

الاكتشاف واختيار الطريق والقبول قرارات مترابطة، لكنها ليست قرارًا واحدًا.

عاد ACK بطبقة أخرى من الحقيقة

أظهر TCP أن جودة الاتجاه الأمامي لا تكفي. ينظم المرسل إرساله بواسطة إقرارات تعود في الاتجاه المعاكس. إذا تلقت البيانات معاملة جيدة وتلقت الإقرارات معاملة مختلفة، فإن الأداء النهائي نتاج الاتجاهين.

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

عداد طابور واحد لا يستطيع أن يشهد على تجربة تطبيق كاملة.

القياس قبل التسعير

فصلت RFC 2990 بين قياس الموارد من أجل القبول وقياس الخدمة بعد التسليم. الأول يجيب: هل يمكن إضافة الحمل؟ والثاني يجيب: هل طابقت النتيجة المواصفات؟

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

توقعت الوثيقة أن تحمل الخدمات الممتازة زيادة في التعرفة. يمكن للسعر أن ينسب كلفة الموارد الإضافية وأن يحد الطلب. لكنها سجلت أن نموذج محاسبة QoS وطريقة جمع البيانات لربط الاستخدام بعميل معين لم يكونا معرفين.

الهوية والاستحقاق والطلب والقبول وتخصيص الموارد والقياس ونسبة الاستخدام وقاعدة السعر والفاتورة سلسلة. القفز من علامة الحزمة إلى الفاتورة يحول حقيقة تقنية صغيرة إلى ادعاء اقتصادي واسع.

مترجم بين الفرد والمجموع

عرضت RFC 2998 طريقة لعبور طلبات IntServ منطقة DiffServ. احتفظ RSVP بالحوار الفردي مع التطبيق، بينما مثلت منطقة DiffServ عنصرًا مجمعًا على المسار. عند الحدود يُترجم وصف التدفق إلى تجميع ملائم.

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

ترجمة النجاح نصف العقد فقط. ترجمة الفشل تحمي دقة الطرف من أن تضيع في التجميع.

تنوع بلا مركز واحد

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

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

توضح عدسة «المواصفة الأولية الدنيا» لدى Lu Heng هذا التوازن. تحدد الطبقة المشتركة الحد الأدنى لتبادل الطلب والسعة والقرار والنتيجة، وتترك قرارات الموارد المستقبلية محلية. لكن القرار المحلي لا يمنح صاحبه حق الصمت تجاه من يعتمد عليه.

وتفصل عدسة طبقات الواقع بين الرمز والقبول، وبين القبول والسعة، وبين المعاملة والأداء، وبين القياس والمحاسبة، وبين سجل الاستخدام والفاتورة. الشيفرة العاملة هي التي تنتج الوصلات المفقودة.

كان من حق الشبكة أن ترفض. الخلل كان أن تستطيع الرفض بلا جواب.

المصادر