الخلاصة

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

بدت الحجزات أكبر من اللازم لأن أحد الموجّهات كان يعرف شيئاً لا يستطيع المضيف الطرفي إدخاله بأمان في رقم شامل للمسار. في المثال المحسوب في RFC 3006، وصف المرسل تدفقاً سرعته 48 كيلوبت في الثانية وحزمته 120 بايتاً. كانت واجهة محدودة السعة تستطيع ضغط ترويسة IP وUDP وRTP من 40 بايتاً إلى أربعة. على تلك الوصلة وحدها تشغل الحزمة 70 في المئة من حجمها الأصلي، فيمكن حساب 33.6 كيلوبت بدلاً من 48.

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

حل RFC 3006 عدم التطابق من دون منح أي طرف سلطة عالمية. بقيت Sender TSpec المرسلة كما هي، اتساقاً مع استعمال RSVP الموصوف في RFC 2210. وأضيف تلميح يحدد نوع الضغط الممكن وعامل نسبة مئوية اختياري. تستطيع عقدة الشبكة إدخاله في اشتقاق TSpec مضغوطة محلية. اختيار كلمة «تلميح» كان حاسماً: ليست أمراً لكل موجّه، ولا برهاناً على أن الوفر سيقع.

هذا الفصل امتداد لتقسيم العمل في RSVP. يحمل RFC 2205 المعلومات بين الأطراف وعناصر الشبكة، لكن قبول الحجز وضبط الحركة يقرران هل الموارد موجودة وكيف تحمى. وضع RFC 3006 التلميح داخل Sender TSpec لأن المرسل أقرب إلى وصف بنية التدفق، ولأن traffic control، لا مجرد معالجة رسالة RSVP، هو الذي يحتاجه. الجسم المشترك يحمل ادعاءً؛ والبرنامج العامل على الوصلة يقرر إن كان الادعاء ذا قيمة تشغيلية.

جعل المثال الحساب قابلاً للمراجعة. كان معدل token bucket، أي r، يساوي 48 كيلوبت في الثانية، وعمقه b يساوي 120 بايتاً، وأقصى حجم للحزمة M يساوي 120، وأدنى وحدة خاضعة للمراقبة m تساوي 64. خفض العامل البالغ 70 في المئة r إلى 33.6، وخفض b وM إلى 84 بايتاً. أما m فلم تحسب بضرب آلي؛ أزيلت منها 36 بايتاً هي فرق الترويسة، فأصبحت 28. لم تكن القاعدة «اضرب كل حقل في 0.7».

في نموذج ضغط الترويسة الذي يزيل عدداً ثابتاً N من البايتات، ضربت الوثيقة المعدل وعمق الاندفاع في f/100، وأبقت معدل الذروة بلا تغيير، وطرحت N من الحدين الأقصى والأدنى للحزمة. لكنها حذرت من أن هذا الوصف لا يلائم كل خوارزمية. وجود checksum في UDP، وانتظام طابع RTP الزمني، وتوزيع أحجام الحزم كلها تغير النتيجة. لذلك يستطيع الموجّه اعتماد عامل أكثر تحفظاً من العامل الذي اقترحه المرسل. العامل صفر يترك الحساب للعقد، و100 يعني عدم توقع وفر.

كان لا بد أيضاً من معالجة حجوزات متعددة المرسلين. تُخفض TSpec لكل مرسل بعامله الخاص قبل جمع المواصفات التي يغطيها الحجز. وفي guaranteed service وفق RFC 2212، يمكن خفض معدل المستقبل بعامل متوسط موزون بأحجام الاندفاع. غير أن خفض R وحده يزيد مساهمة C/R في التأخير، لذلك يرفع الموجّه حد الخطأ C بصورة عكسية. لا يصح خصم السعة إذا غيّر ضمنياً ضمان التأخير الذي طلبه المستقبل.

تبدأ الحجة الأهم بعد انتهاء الحساب المتفائل. الضغط غير حتمي تماماً. إذا قبل الموجّه تدفق 48 على فرض أنه سيستهلك 33.6، ثم بلغ المعدل المضغوط الحقيقي 35، فإن 1.4 كيلوبت الإضافية لم تُحجز. تصبح حركة زائدة وتعاملها الشبكة وفق قواعد خدمة Integrated Services المختارة. التقدير لا يتحول إلى استحقاق لمجرد أنه مكّن القبول.

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

هذه إعادة دقيقة لمكان المسؤولية. لا يفرض RSVP المراقبة في كل عقدة. لكن العقدة الواعية بالضغط خلقت حد موارد محلياً لا تستطيع الحافة الأصلية رؤيته. تستطيع مراقبة المنبع إثبات بقاء المرسل داخل 48 كيلوبت؛ ولا تستطيع إثبات أن الوصلة اللاحقة لم تستقبل أكثر من 33.6. من ينفق الوفر يصبح نقطة التحقق منه.

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

أكملت قابلية التوافق الحلقة. الموجّه القديم الذي لا يفهم التلميح يُفضّل أن يتجاهله محلياً، ويمرره من دون تغيير، ويحجز وفق TSpec الأصلية. وقد تستخدمه عقدة قادرة لاحقة. لكن RFC 2210 لم يحسم آنذاك سلوك كل معامل مجهول، فربما ترفض بعض التطبيقات رسالة PATH. سمح RFC 3006 بإرجاع PathErr ثم المحاولة مجدداً من دون التلميح. يسقط الامتداد إلى العقد الأغلى المفهوم بدلاً من اختراع خصم صامت.

تحدد الأعمال المجاورة ما لا تملكه هذه المقالة. حسب RFC 2688 كلفة PPP الفعلية على السلك بعد التأطير والتجزئة وbyte stuffing وتغير معدل الوصلة. وشرح RFC 2689 لماذا يلزم تعاون التأطير والضغط والمعرفة الصريحة بالتطبيق على الوصلات شحيحة السعة. أما RFC 3006 فركز على الصلة الأضيق بين الادعاء والإنفاذ: من يصف قابلية الضغط، ومن يحولها إلى سعة محلية، ومن يتحمل الخسارة إذا خابت.

لاحقاً خصص RFC 3241 عائلة من قيم التلميح في RSVP لضغط ROHC فوق PPP، واستند معيارياً إلى RFC 3006. يثبت ذلك إمكان توسيع صيغة التلميح إلى إطار ضغط آخر. ولا يثبت انتشاراً واسعاً أو نجاحاً تجارياً أو سلسلة سببية إلى QoS المعاصر. القيمة التاريخية هي بنية القرار الظاهرة في المعيار نفسه.

من منظور Running-Code Primacy عند Lu Heng، جاءت سلطة الموجّه من قدرة قابلة للتنفيذ، لا من امتلاك رقم داخل جسم إشارة. وحمل الحد الأدنى المشترك معلومة تكفي لقرار محلي، من دون إجبار كل عقدة على مستقبل واحد. أما اختبار الاستقرار فعملي: يظل الحجز مستقراً فقط ما دامت نتيجة الضغط المرصودة تسند الخصم الذي بُني عليه القبول.

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

Sources