الخدمات المميزة لتطبيق جودة الخدمة ضمن الشبكات الحاسوبية

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

لنفترض أننا قررنا تحسين نموذج الخدمة بأفضل جهد من خلال إضافة صنفٍ جديد واحدٍ فقط، والذي سنطلق عليه اسم "تفضيلي premium". من الواضح أننا سنحتاج إلى طريقةٍ ما لاكتشاف الرزم التفضيلية عن رزم أفضل جهد قديمة اعتيادية، وسيكون من الأسهل كثيرًا إذا تمكنت الرزم من التعريف عن نفسها للموجّه عند وصولها، بدلًا من استخدام بروتوكول مثل بروتوكول RSVP لإخبار جميع الموجهات بأن بعض التدفقات ترسل رزمًا تفضيلية، ويمكن ذلك باستخدام بتٍ في ترويسة الرزمة، فإذا كان هذا البت هو 1، فإن الرزمة هي رزمة مميزة؛ وإذا كانت قيمة البت 0، فإن الرزمة هي رزمة أفضل جهد. لكن هناك سؤالان نحتاج إلى معالجتهما هما:

من الذي يحدّد البت المميز وتحت أي ظروف؟
ما الذي يفعله الموجّه بصورةٍ مختلفة عندما يرى رزمة مع ضبط هذا البت؟

هناك العديد من الإجابات المحتملة على السؤال الأول، ولكن هناك نهجٌ شائع يتمثل في ضبط البت عند الحدود الإدارية، فقد يضبط الموجهُ الموجود على حافة شبكة مزود خدمة الإنترنت البتَ للرزم التي تصل إلى الواجهة التي تتصل بشبكةِ شركةٍ معينة على سبيل المثال، وقد يفعل مزود خدمة الإنترنت ذلك لأن هذه الشركة قد دفعت مقابل مستوى خدمةٍ أعلى من أفضل جهد. من الممكن أيضًا ألا تكون جميع الرزم تفضيلية؛ فعلى سبيل المثال قد يُضيَط الموجه لوضع علامةٍ على الرزم بأنها رزمٌ تفضيلية لتلك التي تصل إلى الحد الأقصى للمعدل وترك كل الرزم الزائدة رزمًا بأفضل جهد على سبيل المثال.

بافتراض أنه وُضِعت علامات لتمييز الرزم بطريقةٍ ما، فماذا تفعل الموجهات بهذه الرزم المميزة بعلامة التي تواجهها؟ هناك العديد من الإجابات. وحّدت منظمة IETF مجموعةً من سلوكيات الموجّه لتطبيقها على الرزم المميزة بعلامة يُطلق عليها سلوكيات كل قفزة per-hop behaviors أو اختصارًا PHBs، وهو مصطلحٌ يشير إلى أنها تحدّد سلوك كل موجهٍ بدلًا من خدمات طرفٍ إلى طرف. بما أن هناك أكثر من سلوكٍ جديد، فتوجد حاجةٌ أيضًا إلى أكثر من 1 بت في ترويسة الرزمة لإخبار الموجهات بالسلوك الذي يجب تطبيقه. قررت IETF أخذ بايت TOS القديم من ترويسة IP، والذي لم يُستخدَم على نطاقٍ واسع، مع إعادة تعريفه، كما جرى تخصيص ستة بتات من هذا البايت لنقاط شيفرة DiffServ أو اختصارًا DSCPs، حيث تكون كل نقطة DSCP عبارةً عن قيمة مؤلفةٍ من 6 بتات تحدد PHB معينة لتُطَّبق على الرزمة، ويستخدم ECN البتين المتبقيين.

سلوك PHB للتمرير العاجل

يُعرف سلوك التمرير العاجل expedited forwarding أو اختصارًا EF أنه واحدٌ من أبسط PHBs بالشرح، حيث يجب تمرير الرزم المميزة لمعالجة EF بواسطة الموجّه بأقل تأخيرٍ وخسارة، والطريقة الوحيدة التي يمكن أن يضمن بها الموجه ذلك لجميع رزم EF هي إذا كان معدل وصول رزم EF إلى الموجه محدودًا بصورةٍ صارمة ليكون أقل من المعدل الذي يمكن للموجّه من خلاله تمرير رزم EF. يحتاج الموجه بواجهة 100 ميجابت في الثانية على سبيل المثال إلى التأكد من أن معدل وصول رزم EF المخصصة لتلك الواجهة لا يتجاوز أبدًا 100 ميجابت في الثانية، وقد يرغب أيضًا في التأكد من أن المعدل سيكون إلى حدٍ ما أقل من 100 ميجابت في الثانية، بحيث يكون لديه وقت لإرسال رزمٍ أخرى مثل تحديثات التوجيه.

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

هناك العديد من استراتيجيات التطبيق الممكنة لسلوك EF، حيث تتمثل الأولى بإعطاء رزم EF أولويةً صارمةً على جميع الرزم الأخرى، وهناك طريقةٌ أخرى تتمثل في إجراء رتلٍ عادلٍ موزون weighted fair queuing بين رزم EF والرزم الأخرى، مع إعطاء مجموعة EF وزنًا كافيًا، بحيث يمكن تسليم جميع رزم EF بسرعة؛ هذا له أفضليةٌ على الأولوية الصارمة، حيث يمكن ضمان حصول الرزم غير التابعة لمجموعة EF على بعض الوصول إلى الرابط، حتى إذا كان مقدار حركة مرور EF مفرطًا؛ وقد يعني هذا أن رزم EF تفشل في الحصول على السلوك المحدد تمامًا، ولكنه من الممكن أيضًا منع حركة مرور التوجيه الأساسية من أن تُحظر في الشبكة في حالة الحمل الزائد لحركة مرور EF.

سلوك PHB للتمرير المؤكد

تعود جذور سلوك PHB للتمرير المؤكد assured forwarding أو اختصارًا AF إلى نهجٍ يُعرف باسم RED with In and Out أو اختصارًا RIO، أو نهج RED الموزون، وكلاهما يُعَدّان من التحسينات لخوارزمية RED الأساسية الموضحة في قسمٍ سابق. يوضح الشكل التالي كيفية عمل RIO؛ حيث نرى زيادة احتمالية الإسقاط على المحور y مع زيادة متوسط طول الرتل على طول المحور x كما هو الحال مع RED، ولكن لدينا منحنيان منفصلان لاحتمال الإسقاط بالنسبة لصنفي حركة المرور، حيث يستدعي RIO الصنفين "in" و"out" لأسبابٍ ستتضح قريبًا، ويحتوي المنحنى "out" على أدنى عتبة MinThreshold من منحنى "in"، لذلك من الواضح أنه في ظل المستويات المنخفضة من الازدحام، إذ ستُهمَل الرزم المميزة على أنها "out" فقط بواسطة خوارزمية RED إذا أصبح الازدحام أخطر، تُسقَط نسبة أعلى من رزم "out"، وبعد ذلك إذا تجاوز متوسط طول الرتل Min_in، ستبدأ RED في إسقاط رزم "in" أيضًا.

ينبع سبب استدعاء صنفي الرزم "in" و"out" من طريقة تمييز الرزم. لقد لاحظنا أنه يمكن فعليًا إجراء وضع العلامات على الرزم بواسطة موجهٍ على حافة النطاق الإداري، حيث يمكننا التفكير في هذا الموجّه على أنه يقع على الحدود بين مزود خدمة الشبكة وبعض عملاء تلك الشبكة، وقد يكون العميل أي شبكةٍ أخرى، مثل شبكة شركة أو مزود خدمة شبكةٍ آخر، كما قد يوافق العميل ومزود خدمة الشبكة على ملفٍ شخصي للخدمة المؤكَّدة، وقد يدفع العميل لمزود خدمة الشبكة من أجل هذا الملف الشخصي. من الممكن أن يكون الملف الشخصي شيئًا مثل "يُسمح للعميل X بإرسال ما يصل إلى y ميجابت في الثانية من حركة المرور المؤكّدة"، أو قد يكون أعقد، لكن مهما كان ملف التعريف، يمكن لجهاز التوجيه الحدودي تحديد الرزم التي تصل من هذا العميل على أنها إما داخل أو خارج ملف التعريف. طالما أن العميل يرسل أقل من y ميجابت في الثانية في المثال المذكور للتو، ستُوضع علامة "in" على جميع الرزم الخاصة به، ولكن ستوضَع علامة "out" على الرزم الزائدة بمجرد تجاوز هذا المعدل.

يجب أن يوفّر الجمع بين مقياس ملف التعريف على الحافة وRIO في جميع الموجّهات الخاصة بشبكة مزود الخدمة تأكيدًا عاليًا للعميل ولكن ليس ضمانًا بامكانية تسليم الرزم الموجودة في ملفه الشخصي. إذا كانت غالبية الرزم بما في ذلك تلك التي أرسلها العملاء الذين لم يدفعوا مبلغًا إضافيًا لإنشاء ملف تعريف هي رزم "out"، فمن المفترض أن تعمل آلية RIO على إبقاء الازدحام منخفضًا بما يكفي لتكون رزم "in" نادرة الإسقاط. من الواضح أنه يجب أن يكون هناك حيز نطاقٍ تراسلي كافٍ في الشبكة بحيث نادرًا ما تكون رزم "in" وحدها قادرةً على جعل رابطٍ مزدحمًا إلى النقطة التي تبدأ فيها RIO في إسقاط رزم "in".

تعتمد فعالية آليةٍ مثل RIO إلى حدٍ ما على خيارات المعاملات الصحيحة تمامًا كما هو الحال في RED، وهناك المزيد من المعاملات التي يجب تعيينها لآلية RIO. إحدى خصائص RIO المثيرة للاهتمام هي أنها لا تغير ترتيب رزم "in" و"out"، فإذا كان اتصال TCP يرسل رزمًا عبر مقياس ملف تعريف على سبيل المثال، ووُضِعت علامةٌ على بعض رزم "in" بينما وُضِعت علامة "out" على رزمٍ أخرى؛ فستتلقى هذه الرزم احتمالات إسقاط مختلفة في أرتال الموجّه، ولكنها ستُسلَّم إلى المتستقبِل بنفس الترتيب الذي أُرسلت به. هذا مهمٌ لمعظم تطبيقات TCP التي تعمل بصورةٍ أفضل عند وصول الرزم بالترتيب، حتى لو كانت مصممةً للتعامل مع وجود أخطاءٍ في الترتيب. لاحظ أيضًا أنه يمكن تشغيل آلياتٍ مثل إعادة الإرسال السريع بصورةٍ خاطئة عند حدوث خطأٍ في الترتيب.

يمكن تعميم فكرة RIO لتقديم أكثر من منحنيين لاحتمالية الإسقاط، وهذه هي الفكرة وراء النهج المعروف باسم RED الموزون weighted RED أو اختصارًا WRED. تُستخدَم قيمة حقل DSCP في هذه الحالة لاختيار منحنى من العديد من منحنيات احتمالية السقوط، بحيث يمكن توفير عدة أصنافٍ مختلفة من الخدمة.

تتمثل الطريقة الثالثة لتقديم خدماتٍ مميزة في استخدام قيمة DSCP لتحديد الرتل الذي يجب وضع رزمة فيه في مجدول رتلٍ عادلٍ وموزون. قد نستخدم نقطة شيفرةٍ code point واحدة للإشارة إلى رتل رزم أفضل جهد best-effort ونقطة شيفرة ثانية لتحديد رتل الرزم التفضيلية premium، وسنحتاج بعد ذلك إلى اختيار وزنٍ لرتل الرزم التفضيلية الذي يجعلها تحصل على خدمة أفضل من الرزم الأفضل جهدًا، وهذا يعتمد على الحِمل المعروض على الرزم التفضيلية، فإذا منحنا رتل الرزم التفضيلية وزنًا قدره 1 على سبيل المثال ورتل الأفضل جهدًا وزنًا قدره 4، فهذا يضمن أن حيز النطاق التراسلي المتاح للرزم المميزة هو:

B_premium = W_premium / (W_premium + W_best-effort) = 1/(1 + 4) = 0.2

وهذا يعني أننا حجزنا فعليًا 20% من الرابط للرزم التفضيلية، لذلك إذا كان الحِمل المعروض على حركة المرور التفضيلية هو 10% فقط من الرابط وسطيًا، فستتصرف حركة المرور التفضيلية كما لو كانت تعمل على شبكةٍ ذات حِملٍ منخفض جدًا وستكون الخدمة جيدةً جدًا. يمكن الإبقاء على التأخير الذي يعاني منه الصنف التفضيلي premium class منخفضًا، حيث سيحاول WFQ إرسال الرزم التفضيلية بمجرد وصولها في هذا السيناريو. إذا كان الحِمل لحركة المرور التفضيلية 30%، فسيتصرف مثل شبكةٍ محمَّلةٍ بصورةٍ كبيرة، وقد يكون التأخير مرتفعًا للغاية بالنسبة للرزم التفضيلية، بل أسوأ من رزم الأفضل جهدًا، وبالتالي فإن معرفة الحِمل المعروض والإعداد الدقيق للأوزان أمرٌ مهم لهذا النوع من الخدمة. نلاحظ أن النهج الآمن هو أن تكون متحفظًا للغاية في تحديد وزن رتل الرزم التفضيلية، فإذا كان هذا الوزن مرتفعًا جدًا بالنسبة للحِمل المتوقع، فإنه يوفر هامشًا للخطأ ولكنه لا يمنع حركة المرور الأفضل جهدًا من استخدام أي حيز نطاقٍ تراسلي محجوزٍ للرزم التفضيلية ولكنها لم تستخدمه.

يمكننا تعميم هذا النهج المستند إلى WFQ كما في WRED للسماح بأكثر من صنفين مُمثلَين بنقاط شيفرةٍ مختلفة، ويمكننا دمج فكرة محدد الرتل queue selector مع نظام تفضيل الإسقاط؛ فيمكن أن يكون لدينا على سبيل المثال أربعة أرتال بأوزانٍ مختلفة من خلال 12 نقطة شيفرة، لكلٍ منها ثلاثة تفضيلات إسقاط. هذا هو بالضبط ما فعلته منظمة IETF في تعريف "الخدمة المؤكدة assured service".

ترجمة -وبتصرّف- للقسم Quality of Service من فصل Congestion Control من كتاب Computer Networks: A Systems Approach.