البحث في الموقع

لقد رأينا طبقاتٍ كافية من تسلسل بروتوكول الشبكة الهرمي لفهم كيفية نقل البيانات بين العمليات عبر الشبكات غير المتجانسة، وسننتقل الآن إلى مشكلةٍ تمتد على كامل مكدّس البروتوكولات، وهي كيفية تخصيص الموارد بفعاليةٍ وعدالةٍ بين مجموعةٍ من المستخدمين المتنافسين، حيث تشمل الموارد المشاركة حيّز نطاق الروابط التراسلي والمخازن المؤقتة على الموجّهات أو المبدّلات، إذ تُوضَع الرزم في رتلٍ في انتظار الإرسال. وتتنافس الرزم على موجّهٍ لاستخدام رابطٍ، حيث تُوضع كل رزمةٍ متنافسة في رتلٍ انتظارًا لدورها وإرسالها عبر الرابط. عند تنافس عدد كبير جدًا من الرزم على نفس الرابط يمتلئ الرتل ويحدث شيئان غير مرغوبٍ فيهما هما: تعرُّض الرزم لتأخير طرفٍ إلى طرف، وفي أسوأ الحالات يحدث طفحانًا للأرتال وإسقاطًا drop للرزم، ويُقال هنا أن الشبكة مزدحمة عندما يستمر حدوث الأرتال الطويلة ويصبح إسقاط الرزم أمرًا شائعًا، لذلك توفِّر معظم الشبكات آليةً للتحكم في الازدحام للتعامل مع مثل هذا الموقف. يُعَد التحكم في الازدحام وتخصيص الموارد وجهان لعملة واحدة، أي من الممكن تجنب الازدحام إذا لعبت الشبكة دورًا نشطًا في تخصيص الموارد مثل جدولة أي دارةٍ افتراضية يمكنها استخدام رابط فيزيائي معيّن خلال فترةٍ زمنيةٍ معينة، وهذا ما يجعل التحكم في الازدحام أمرًا غير ضروري. من الصعب تخصيص موارد الشبكة بدقة لأن الموارد المعنية موزعةٌ في جميع أنحاء الشبكة؛ وبالتالي يجب جدولة الروابط المتعددة التي تربط سلسلةً من الموجّهات. من جهةٍ أخرى، يمكن السماح دائمًا لمصادر الرزم بإرسال أكبر قدرٍ تريده من البيانات ثم التعافي من الازدحام في حالة حدوثه، وهذا هو النهج الأسهل رغم أنه قد يكون معطِّلًا، وذلك لأن الشبكة قد تتجاهل العديد من الرزم قبل أن يحدث التحكم في الازدحام. يكون الشعور بالحاجة إلى تخصيص الموارد بين المستخدمين المتنافسين شديدًا في الأوقات التي تكون فيها الشبكة مزدحمة، أي عندما تصبح الموارد قليلةً مقابل الطلب. هناك أيضًا حلول في الوسط، حيث تُتخَذ قرارات تخصيصٍ غير دقيقة، ولكن لا يزال من الممكن حدوث الازدحام، وبالتالي لا تزال هناك حاجة إلى آلية للتعافي منه، ولا يهم حقًا فيما إذا سُميت مثل تلك الحلول بحلول التحكم في الازدحام المختلطة أو تخصيص الموارد أو كليهما. يتضمن التحكم في الازدحام وتخصيص الموارد كلًا من المضيفين وعناصر الشبكة مثل الموجهات، ويمكن استخدام أنظمة أرتال مختلفة في عناصر الشبكة للتحكم بترتيب إرسال الرزم والتحكم في الرزم المُهمَلة dropped، وكذلك فصل حركة المرور لمنع رزم أحد المستخدمين من التأثير غير المناسب على رزم مستخدمٍ آخر؛ حيث تحدِّد آلية التحكم في الازدحام في المضيفين النهائيين مدى السرعة المسموح بها للمصادر بإرسال الرزم في محاولةٍ لمنع حدوث الازدحام في المقام الأول، وللمساعدة في القضاء على الازدحام في حالة حدوثه. سنبدأ بنظرة عامة على التحكم في الازدحام وتخصيص الموارد، ونناقش بعد ذلك مختلف أنظمة الأرتال الممكن تنفيذها على الموجّهات داخل الشبكة متبوعةً بوصف خوارزمية التحكم في الازدحام التي يوفرها بروتوكول TCP على المضيفين، بعدها سنكتشف العديد من التقنيات التي تتضمن كلًا من الموجهات والمضيفين، والتي تهدف إلى تجنب الازدحام قبل أن يصبح مشكلة، وفي الأخير سندرس المجال الواسع لجودة الخدمة. يجب الأخذ في الحسبان احتياجات التطبيقات لتلقي مستويات مختلفة من تخصيص الموارد في الشبكة مع وصف عددٍ من الطرق الممكن لتلك التطبيقات طلب هذه الموارد من خلالها وإمكانية تلبية الشبكة لها. مشاكل تخصيص الموارد يُعد تخصيص الموارد والتحكم في الازدحام من القضايا المعقدة التي كانت موضوع الكثير من الدراسات منذ تصميم الشبكة الأولى، ولا تزال ضمن مجالات بحث نشطة. أحد العوامل التي تجعل هذه القضايا معقدةً هو أنها ليست معزولةً بمستوى واحد من تسلسل البروتوكول الهرمي. يُطبَّق تخصيص الموارد جزئيًا في الموجّهات والمبدلات والروابط داخل الشبكة والجزء الآخر في بروتوكول النقل الذي يعمل على المضيفين النهائيين، وقد تستخدم الأنظمة الطرفية بروتوكولات إصدار الإشارات signalling لنقل متطلباتها من الموارد إلى عقد الشبكة التي تستجيب بمعلوماتٍ حول توفُّر الموارد. يتمثل أحد الأهداف الرئيسية لهذا الفصل في تحديد إطارٍ يمكن من خلاله فهم هذه الآليات، إلى جانب تقديم التفاصيل ذات الصلة حول عينة تمثيلية من الآليات. يجب توضيح مصطلحاتنا قبل المُضي قدمًا، حيث نعني بعملية تخصيص الموارد؛ العمليةَ التي تحاول من خلالها عناصر الشبكة تلبية المتطلبات المتنافسة التي تمتلكها التطبيقات لموارد الشبكة، مثل مساحة المخزن المؤقت وحيّز نطاق الرابط التراسلي في الموجّهات أو المبدلات. من الممكن عدم تلبية جميع المتطلبات في كثير من الأحيان، مما يعني أن بعض المستخدِمين أو التطبيقات قد تتلقى موارد شبكة أقل مما تريد، ويتمثل جزء من مشكلة تخصيص الموارد في تحديد متى يجب أن تقول لا ولمن. نستخدم مصطلح التحكم في الازدحام لوصف الجهود التي تبذلها عقد الشبكة لمنع حالات الحِمل الزائد أو الاستجابة لها. وبما أن الازدحام سيئٌ عمومًا للجميع، فلابُد من تخفيف الازدحام أو منعه في المقام الأول، ويمكن تحقيق ذلك ببساطة عن طريق إقناع عددٍ قليل من المضيفين بالتوقف عن الإرسال وبالتالي تحسين الوضع لأي شخصٍ آخر، ولكن من الشائع أكثر أن يكون لآليات التحكم في الازدحام بعض جوانب الإنصاف، حيث أنها تحاول مشاركة الألم بين جميع المستخدمين بدلًا من التسبب في ألم شديد لعدد قليل، وهكذا نرى أن العديد من آليات التحكم في الازدحام تحتوي على نوعٍ من تخصيص الموارد مضمَّنٌ فيها. من المهم أيضًا فهم الفرق بين التحكم في التدفق flow control والتحكم في الازدحام congestion control؛ حيث يتضمن التحكم في التدفق منع المرسل السريع من تجاوز مستقبِلٍ بطيء؛ بينما يهدف التحكم في الازدحام إلى منع مجموعةٍ من المرسلين من إرسال الكثير من البيانات إلى الشبكة بسبب نقص الموارد في مرحلةٍ ما، ويُخلَط غالبًا بين هذين المفهومين حيث يتشاركان أيضًا في بعض الآليات. نموذج الشبكة نبدأ بتحديد ثلاث سماتٍ بارزةٍ لمعمارية الشبكة، ولكن الجزء الأكبر من هذا القسم هو ملخصٌ للأفكار المقدَّمة في الفصول السابقة ذات الصلة بمشكلة تخصيص الموارد. شبكة تبديل الرزم سنفترض تخصيص الموارد في شبكة تبديل الرزم Packet-Switched Network (أو الإنترنت)، والتي تتكون من روابط ومبدلاتٍ (أو موجّهات) متعددة، كما سنستخدم مصطلح الموجّه طوال مناقشتنا نظرًا لأن معظم الآليات الموضحة في هذا الفصل مصمَّمة للاستخدام على شبكة الإنترنت، وبالتالي عُرِّفت في الأصل باستخدام الموجهات بدلًا من المبدلات، ولكن المشكلة هي نفسها سواءٌ كانت على شبكةٍ أو عبر شبكةٍ متشابكة internetwork مثل شبكة الإنترنت. قد يكون لمصدرٍ معين في مثل هذه البيئة سعةً كافيةً على الرابط الصادر المباشر لإرسال رزمة، ولكن تواجه الرزم رابطًا تستخدمه مصادرُ حركة مرور مختلفة في مكانٍ ما في منتصف الشبكة. يوضح الشكل الآتي هذا الموقف، فهناك رابطان عاليا السرعة يغذّيان رابطًا منخفض السرعة؛ وهذا على عكس شبكات الوصول المشترك مثل شبكة إيثرنت والشبكات اللاسلكية، حيث يمكن للمصدر مراقبة حركة المرور مباشرةً على الشبكة واتخاذ قرارٍ بإرسال رزمةٍ أم لا. لقد رأينا فعليًا الخوارزميات المستخدمة لتخصيص حيز النطاق التراسلي على شبكات الوصول المشترك مثل شبكات Ethernet وWi-Fi، حيث تُعَد خوارزميات التحكم في الوصول هذه مماثلة إلى حدٍ ما لخوارزميات التحكم في الازدحام في شبكة التبديل. لاحظ أن مشكلة التحكم في الازدحام مختلفة عن التوجيه، حيث يمكن أن يُسنَد للرابط المزدحم وزن حافةٍ كبير من خلال بروتوكول التوجيه، لذلك فإن الموجّهات ستسير حوله، ولكن لن يحل "التوجيه حول routing around" الرابط المزدحم مشكلة الازدحام. لا نحتاج إلى النظر لأبعد من الشبكة البسيطة الموضحة في الشكل الآتي لرؤية هذا، حيث يجب أن تتدفق كل حركة المرور عبر نفس الموجّه للوصول إلى الوجهة. قد يكون هذا مثالًا متطرفًا، إلا أنه من الشائع أن يكون لديك موجّهٌ معين لا يمكن التوجيه حوله، فربما يصبح هذا الموجه مزدحمًا، ولا يوجد شيءٌ يمكن أن تفعله آلية التوجيه حيال ذلك. يسمى هذا الموجه المزدحم أحيانًا "موجّه عنق الزجاجة bottleneck router". التدفقات عديمة الاتصال نفترض أن الشبكة عديمة الاتصال Connectionless بصورةٍ أساسية بالنسبة للكثير من مناقشتنا، ومع أية خدمة موجَّهةٍ بالاتصال، ومطبَّقةٍ في بروتوكول النقل الذي يعمل على المضيفين النهائيين. هذا هو بالضبط نموذج الإنترنت، حيث يوفِّر بروتوكول IP خدمة توصيل مخطط بيانات عديمة الاتصال ويطبّق بروتوكول TCP تجريد اتصال من طرفٍ إلى طرف مع الملاحظة أن هذا الافتراض لا ينطبق على شبكات الدارات الافتراضية مثل ATM وX.25، حيث تعبر في مثل هذه الشبكات رسالةُ إعداد الاتصال الشبكةَ عند إنشاء دارة، وتحتفظ رسالة الإعداد هذه بمجموعة من المخازن المؤقتة للاتصال في كل موجّه، مما يوفر شكلًا من أشكال التحكم في الازدحام، حيث يُنشَأ اتصالٌ فقط إذا كان من الممكن تخصيص مخازن مؤقتة كافية له في كل موجه، لكن يتمثل العيب الرئيسي في هذا النهج في أنه يؤدي إلى نقص استخدام الموارد، حيث لا تتوفر المخازن المؤقتة المحجوزة لدارة معينة للاستخدام من قِبل حركة المرور الأخرى، حتى لو لم تكن تستخدمها تلك الدارة حاليًا. ينصب التركيز في هذا الفصل على مناهج تخصيص الموارد التي تنطبق في شبكةٍ متشابكة، وبالتالي فإننا نركز بصورةٍ أساسية على الشبكات عديمة الاتصال. نحتاج إلى تعديل مصطلح "عديمة الاتصال" لأن تصنيفنا للشبكات على أنها إما عديمة الاتصال أو موجَّهة بالاتصال مقيدٌ للغاية؛ فهناك منطقةٌ رمادية بينهما. يُعَد الافتراض القائل بأن جميع مخططات البيانات مستقلة تمامًا في شبكةٍ عديمة الاتصال افتراضًا قويًا للغاية، حيث تُبدَّل بالتأكيد مخططات البيانات بصورةٍ مستقلة، ولكن عادةً ما يكون هناك تدفقٌ من مخططات البيانات بين زوجٍ معينٍ من المضيفين عبر مجموعة معينة من الموجّهات، كما أن فكرة عدِّ التدفق سلسلةً من الرزم المرسلة بين زوج المصدر / الوجهة، واتباع نفس المسار عبر الشبكة فكرةٌ مجردةٌ ومهمةٌ في سياق تخصيص الموارد وهي ماسنستخدمه في هذا الفصل. تتمثل إحدى قوى تجريد التدفق في إمكانية تحديد التدفقات بدرجاتٍ مختلفة، حيث يمكن مثلًا أن يكون التدفق من مضيفٍ إلى مضيف، أي لهما نفس عناوين مضيف المصدر / الوجهة، أو عمليةٍ إلى عملية أي لهما نفس أزواج المصدر / الوجهة المضيف / المنفذ. إن مصطلح التدفق في الحالة الثانية هو في الأساس نفس مصطلح القناة كما كنا نستخدمه في هذا الكتاب، وسبب تقديمنا لمصطلحٍ جديد هو أن التدفق مرئي للموجّهات داخل الشبكة، في حين أن القناة هي تجريد من طرفٍ إلى طرف. يوضح الشكل التالي عدة تدفقات تمر عبر سلسلةٍ من الموجّهات: بما أن العديد من الرزم ذات الصلة تتدفق عبر كل موجّه، فمن المنطقي في بعض الأحيان الاحتفاظ ببعض معلومات الحالة لكل تدفق، وهي المعلومات الممكن استخدامها لاتخاذ قرارات تخصيص الموارد حول الرزم التي تنتمي إلى التدفق، وتسمى هذه الحالة أحيانًا الحالة اللينة soft state، ويتمثل الاختلاف الرئيسي بين الحالة اللينة والحالة القاسية أو الصلبة hard state؛ في عدم الإلتزام دائمًا بإنشاء الحالة اللينة وإزالتها بصورةٍ صريحة عن طريق إصدار الإشارات، كما تمثّل الحالة اللينة أرضيةً وسطية بين شبكةٍ عديمة الاتصال بحتة لا تحتفظ بأية حالةٍ في الموجّهات والشبكة الموجَّهة بالاتصال البحت، والتي تحافظ على الحالة الصلبة في الموجّهات. لا تعتمد الإدارة الصحيحة للشبكة على وجود الحالة اللينة وتُوجَّه كل رزمة بصورةٍ صحيحة بغض النظر عن هذه الحالة، وسيكون الموجّه أكثر قدرةً على التعامل مع الرزمة عندما تنتمي هذه الرزمة إلى تدفقٍ يحتفظ فيه الموجّه حاليًا بالحالة اللينة. لاحظ أنه يمكن تحديد التدفق ضمنيًا أو بصورةٍ واضحة، حيث يراقب كل موجّهٍ في الحالة الأولى الرزمَ المنتقلة بين نفس زوج المصدر / الوجهة، عن طريق فحص العناوين الموجودة في الترويسة، ويتعامل مع هذه الرزم على أنها تنتمي إلى نفس التدفق بغرض التحكم في الازدحام، بينما يرسل المصدر في الحالة الثانية رسالة إعداد التدفق عبر الشبكة معلنًا أن تدفق الرزم على وشك البدء. يمكن القول أن التدفقات الصريحة explicit flows لا تختلف عن الاتصال عبر شبكةٍ موجهةٍ بالاتصال، ولكن لا بد من لفت الانتباه إلى هذه الحالة نظرًا لعدم تضمُّن التدفق أية دلالات من طرفٍ إلى طرف حتى عند تأسيسه بصورةٍ صريحة وعدم شموله للتسليم الموثوق والمرتّب لدارةٍ افتراضية، فهو موجودٌ ببساطة لغرض تخصيص الموارد. سنرى أمثلةً على التدفقات الضمنية والصريحة في هذا الفصل. نموذج الخدمة سنركز في القسم الأول من هذا الفصل على الآليات التي تفترض نموذج خدمة الإنترنت بأفضل جهد، والذي تُعامَل فيه جميع الرزم معاملةً متساويةً مع عدم إعطاء المضيف النهائي أية فرصة لمطالبة الشبكة بمنح بعض الرزم أو التدفقات ضماناتٍ معينة أو خدمة تفضيلية. وسيكون موضوع القسم اللاحق هو تحديد نموذج خدمة يدعم نوعًا من الخدمة أو الضمان المفضل، مثل ضمان حيز النطاق التراسلي المطلوب لبث الفيديو، ويقال أن نموذج الخدمة هذا يوفر جودة خدمةٍ QoS متعددة. هناك في الواقع مجموعةٌ من الاحتمالات تتراوح من نموذج خدمة أفضل جهد بحت إلى نموذجٍ تتلقى فيه التدفقات الفردية ضماناتٍ كميّة بجودة الخدمة، ويتمثل أحد أكبر التحديات في تحديد نموذج خدمةٍ يلبي احتياجات مجموعةٍ واسعة من التطبيقات حتى تلك التطبيقات التي ستُخترع في المستقبل. تصنيف آليات تخصيص الموارد هناك طرقٌ لا حصر لها تختلف فيها آليات تخصيص الموارد، لذا فإن إنشاء تصنيفٍ شامل هو اقتراحٌ صعب. نفسّر حاليًا ثلاثة أبعاد يمكن من خلالها وصف آليات تخصيص الموارد. التصنيف المتمحور حول الموجه مقابل التصنيف المتمحور حول المضيف يمكن تصنيف آليات تخصيص الموارد إلى مجموعتين كبيرتين: تلك التي تعالج المشكلة من داخل الشبكة أي في الموجهات أو المبدلات على سبيل المثال، وتلك التي تعالج المشكلة من حواف الشبكة، أي في المضيفين وربما داخل بروتوكول النقل، وذلك نظرًا لتشارُك الموجّهات داخل الشبكة والمضيفين على حواف الشبكة في تخصيص الموارد، فإن المشكلة الحقيقية تكمن في المكان الذي يقع فيه معظم العبء. في التصميم المتمحور حول الموجّه Router-Centric سيتحمل كل موجهٍ مسؤولية تحديد وقت إعادة توجيه الرزم واختيار الرزم التي ستُهمَل، وكذلك إعلام المضيفين الذين ينشئون حركة مرور الشبكة بعدد الرزم المسموح لهم بإرسالها؛ أما في التصميم المتمحور حول المضيف Host-Centric، فسيراقب المضيفون النهائيون ظروف الشبكة (عدد الرزم التي يحصلون عليها بنجاح عبر الشبكة على سبيل المثال) ويعدّلون سلوكهم وفقًا لذلك. نلاحظ أن هاتين المجموعتين ليستا متعارضتين، فعلى سبيل المثال لا تزال تتوقع الشبكة التي تضع العبء الأساسي في إدارة الازدحام على الموجّهات التزام المضيفون النهائيون بأية رسائل استشارية ترسلها الموجّهات، بينما لا تزال هناك سياسةٌ معينة مهما كانت بسيطة للموجهات في الشبكات التي تستخدم التحكم في الازدحام من طرفٍ إلى طرف لتحديد الرزم التي ستُهمَل عند طفحان الأرتال الخاصة بها. التصنيف القائم على الحجز مقابل التصنيف القائم على الاستجابة الراجعة الطريقة الثانية التي تُصنَّف بها آليات تخصيص الموارد في بعض الأحيان؛ هي وفقًا لاستخدامها الحجز Reservation أو الاستجابة الراجعة Feedback. وفي نظامٍ قائمٍ على الحجز، ستطلب بعض الكيانات مثل المضيف النهائي من الشبكة قدرًا معينًا من السعة لتخصيصها للتدفق، ثم يخصّص كل موجّهٍ بعد ذلك مواردًا كافية، أي مخازن مؤقتة و/ أو نسبةً من حيز نطاق الرابط التراسلي لتلبية هذا الطلب، وعند تعذُّر تلبية الطلب في موجهٍ ما لأن ذلك سيؤدي إلى الإفراط في الالتزام بموارده، فسيرفض هذا الموجّه الحجز، وهذا مشابه للحصول على إشارة مشغول عند محاولة إجراء مكالمة هاتفية؛ أما في النهج القائم على الاستجابة الراجعة، فيبدأ المضيفون النهائيون في إرسال البيانات دون حجز أي سعة أولًا، ثم يضبطون معدل الإرسال وفقًا للاستجابات الراجعة التي يتلقونها. قد تكون هذه الاستجابات الراجعة إما صريحةً مثل إرسال الموجّه المزدحم رسالة "الرجاء الإبطاء" إلى المضيف، أو ضمنيةً مثل ضبط المضيف النهائي معدل الإرسال وفقًا للسلوك الذي يمكن ملاحظته خارجيًا للشبكة مثل فقد رزمة. من المُلاحظ شمول النظام القائم على الحجز على آلية تخصيص مواردٍ تتمحور حول الموجّه دائمًا، وذلك لأن كل موجّهٍ مسؤول عن تتبُّع مقدار سعته المتاحة حاليًا، وتحديد ما إذا كان يمكنه قبول حجوزاتٍ جديدة. قد تضطر الموجهات أيضًا إلى التأكد من أن كل مضيفٍ مستقر داخل الحجز الذي أجراه، وإذا أرسل مضيفٌ البيانات بصورةٍ أسرع مما ادّعى عند إجراء الحجز؛ فستكون رزم هذا المضيف مرشحةً بصورةٍ أكبر للإهمال في حالة ازدحام الموجّه. قد يتضمن النظامُ القائم على الاستجابة الراجعة آليةً متمحورةً حول الموجّه أو حول المضيف، فإذا كانت الاستجابات صريحة، فيسشارك الموجّه إلى حدٍ ما على الأقل في مخطط تخصيص الموارد؛ أما إذا كانت الاستجابات ضمنيةً، فسيقع كل العبء تقريبًا على عاتق المضيف النهائي، حيث تُسقِط الموجّهات الرزم بصمتٍ عندما تصبح مزدحمة. لا يجب أن يجري المضيفون النهائيون الحجز، حيث يمكن لمسؤول الشبكة تخصيص موارد للتدفقات أو لمجموعاتٍ أكبر من حركة المرور كما سنرى لاحقًا. التصنيف القائم على أساس النافذة مقابل التصنيف القائم على المعدل الطريقة الثالثة لتوصيف آليات تخصيص الموارد هي وفقًا لاعتمادها على النافذة Window أو على المعدّل Rate. ويُعَد هذا التصنيف هو أحد المجالات المذكورة أعلاه، حيث تُستخدَم آليات ومصطلحات مماثلة للتحكم في التدفق والتحكم في الازدحام، وتحتاج كل من آليات التحكم في التدفق وتخصيص الموارد إلى وسيلةٍ للتعبير للمرسل عن مقدار البيانات المسموح له بإرسالها، وهناك طريقتان عامتان للتعبير عن ذلك من خلال نافذة أو معدل. لقد رأينا بروتوكولات نقل قائمةٍ على النوافذ مثل بروتوكول TCP، حيث يعلن المستقبِل عن نافذةٍ للمرسل، وتتوافق هذه النافذة مع مقدار مساحة المخزَن المؤقت التي يمتلكها المستقبِل، وتحدّ من مقدار البيانات التي يمكن للمرسل إرسالها؛ وهذا يعني أنه يدعم التحكم في التدفق يمكن استخدام آليةٍ مماثلة لإعلان النافذة داخل الشبكة لحجز مساحة المخزن المؤقت، وبالتالي دعم تخصيص الموارد، حيث تعتمد آليات التحكم في الازدحام في بروتوكول TCP على النافذة. من الممكن أيضًا التحكم في سلوك المرسل باستخدام المعدّل، أي عدد البتات في الثانية الممكن للمستقبل أو الشبكة استيعابها، إذ يُعَد التحكم المستند إلى المعدّل منطقيًا للعديد من تطبيقات الوسائط المتعددة التي تميل إلى إنشاء بياناتٍ بمعدّلٍ متوسط معين، والتي تحتاج على الأقل إلى حدٍ أدنى من الإنتاجية لتكون مفيدة، فقد يُنشِئ برنامج ترميز الفيديو على سبيل المثال فيديو بمعدلٍ متوسط يبلغ 1 ميجابت في الثانية، وبمعدّل ذروة يبلغ 2 ميجابت في الثانية؛ كما يُعَد توصيف التدفقات على أساس المعدل خيارًا منطقيًا في نظامٍ قائمٍ على الحجز ويدعم جودة خدمة مختلفة، حيث يحجز المرسل العديد من البتات في الثانية ويحدّد كل موجهٍ على طول المسار فيما إذا كان يمكنه دعم هذا المعدل من خلال النظر إلى التدفقات الأخرى التي تعهدَ بها. ملخص تصنيف تخصيص الموارد يوحي تصنيف طرق تخصيص الموارد في نقطتين مختلفتين على طول كلٍ من الأبعاد الثلاثة كما فعلنا للتو إلى مايصل لثماني استراتيجياتٍ فريدة. في حين أن هناك ثماني مقاربات مختلفة ممكنة بالتأكيد، إذ نلاحظ أنه من الناحية العملية أنه يبدو أن استراتيجيتين عامتين هما الأكثر انتشارًا، كما ترتبط هاتان الاستراتيجيتان بنموذج الخدمة الأساسي للشبكة. يفترض نموذج الخدمة عادةً أفضل جهد استخدام للاستجابات الراجعة ضمنيًا، وذلك نظرًا لعدم سماح هذا النموذج للمستخدمين بحجز سعة الشبكة، وهذا بدوره يعني أن معظم مسؤولية التحكم في الازدحام تقع على عاتق المضيفين النهائيين، ربما مع بعض المساعدة من الموجّهات. تستخدم هذه الشبكات عمليًا المعلوماتِ المستندة إلى النافذة، وهذه هي الإستراتيجية العامة المعتمدة في الإنترنت. من ناحيةٍ أخرى، قد يتضمن نموذج الخدمة القائم على جودة الخدمة شكلًا من أشكال الحجز، ومن المحتمل أن يتطلب دعم هذه الحجوزات مشاركةً كبيرة للموجّه، مثل وضع الرزم ضمن رتلٍ بطريقةٍ مختلفة اعتمادًا على مستوى الموارد المحجوزة التي تتطلبها، ويمكن التعبير عن هذه الحجوزات من حيث المعدل نظرًا لأن النوافذ مرتبطة بصورةٍ غير مباشرة فقط بكمية حيز النطاق التراسلي التي يحتاجها المستخدم من الشبكة. معايير تقييم آليات تخصيص الموارد المسألة الأخيرة هي معرفة ما إذا كانت آلية تخصيص الموارد جيدةً أم لا. بالعودة إلى بيان المشكلة المذكور في بداية هذا الفصل، فقد طُرح سؤال عن كيفية تخصيص الشبكة لمواردها بصورةٍ فعالة وعادلة، ويشير هذا السؤال إلى مقياسين واضحين على الأقل يمكن من خلالهما تقييم مخطط تخصيص الموارد. تخصيص الموارد الفعال تتمثل نقطة البداية لتقييم فعالية مخطط تخصيص الموارد بافتراض مقياسين رئيسيين للشبكات هما الإنتاجية، والتأخير، فمن الواضح أننا نريد أكبر قدرٍ ممكن من الإنتاجية وأقل تأخيرٍ ممكن، ولكن غالبًا ما تكون هذه الأهداف متعارضةً إلى حدٍ ما مع بعضها بعضًا. ومع ذلك فمن بين إحدى الطرق المؤكدة لزيادة إنتاجية خوارزمية تخصيص الموارد؛ السماح بأكبر عددٍ ممكن من الرزم في الشبكة، وذلك من أجل استخدام جميع الروابط حتى نسبة 100%، حيث نفعل هذا لتجنب احتمال أن يصبح الرابط خاملًا، وهذا يُضِّر بالإنتاجية، وتكمن مشكلة هذه الإستراتيجية في أن زيادة عدد الرزم في الشبكة يزيد أيضًا من طول الأرتال في كل موجّه، وتؤدي الأرتال الأطول بدورها إلى تأخير الرزم لفترةٍ أطول في الشبكة. اقترح بعضُ مصممي الشبكات استخدام نسبة الإنتاجية إلى التأخير مثل مقياس لتقييم فعالية مخطط تخصيص الموارد، ويشار إلى هذه النسبة أحيانًا باسم طاقة الشبكة: Power = Throughput / Delay نلاحظ أنه من غير الواضح بأن الطاقة هي المقياس الصحيح للحكم على فعالية تخصيص الموارد، وذلك لاستناد النظرية الكامنة وراء الطاقة إلى رتل شبكةٍ من النوع M / M / 1 الذي يفترض أرتالًا لا نهائية، حيث أن الشبكات الحقيقية لها مخازنٌ مؤقتة محدودة، وقد تضطر أحيانًا إلى إسقاط الرزم، وبما أن هذا الكتاب ليس كتابًا يشرح نظريات الأرتال، فسنقدّم فقط هذا الوصف الموجز لرتل M / M / 1، حيث 1 يعني أنه يحتوي على خادمٍ واحد، ويشير حرفا M إلى أن توزيع كلٍ من أوقات وصول الرزم والخدمة هو توزيعٌ أسي Markovian. ومن ناحيةٍ أخرى، تُعرَّف الطاقة عادةً بالنسبة إلى اتصالٍ واحد (تدفق) وليس واضحًا كيف تمتد إلى اتصالاتٍ متعددة متنافسة. على الرغم من هذه القيود الشديدة إلى حدٍ ما لكن لم تحظَ أي بدائل أخرى بقبولٍ واسعٍ، وبالتالي يستمر استخدام الطاقة. يُعَد الهدف هنا هو زيادة هذه النسبة إلى الحد الأقصى، وهي دالةٌ لمقدار الحِمل الذي تضعه على الشبكة، ويُضبَط الحِمل بواسطة آلية تخصيص الموارد، حيث يعطي الشكل الآتي منحنىً تمثيليًا للطاقة، إذ تعمل آلية تخصيص الموارد بصورةٍ مثالية في ذروة هذا المنحنى، وتكون الآلية معتدلةً ومستقرةً للغاية على يسار القمة؛ أي أنه لا يُسمَح بإرسال رزمٍ كافيةٍ لإبقاء الروابط مشغولة، ويُسمح بدخول العديد من الرزم إلى الشبكة إلى يمين القمة ويزداد التأخير بسبب الانتظار في الرتل الذي يبدأ بالاستحواذ على أي مكاسبٍ صغيرة في الإنتاجية. ومن المثير للاهتمام أن منحنى الطاقة هذا يشبه إلى حدٍ كبير منحنى إنتاجية النظام في نظام مشاركة الوقت في الحاسوب، حيث يتحسن معدل نقل النظام مع قبول المزيد من الوظائف في النظام حتى يصل إلى نقطةٍ يكون فيها الكثير من المهام قيد التشغيل، ويبدأ النظام بالتأزُّم thrash، حيث يقضي كل وقته في تبديل صفحات الذاكرة ويبدأ معدل النقل في الانخفاض. إن العديد من أنظمة التحكم في الازدحام قادرةٌ على التحكم في الحِمل بطرقٍ بدائية للغاية؛ أي أنه من غير الممكن ببساطة تشغيل "المقبض knob" قليلًا والسماح فقط بعددٍ صغيرٍ من الرزم الإضافية في الشبكة، لذلك يحتاج مصممو الشبكات إلى القلق بشأن ما يحدث حتى عندما يعمل النظام تحت عبءٍ ثقيلٍ للغاية أي في أقصى الطرف الأيمن من المنحنى في الشكل السابق. نود من الناحية المثالية تجنُّب الموقف الذي يذهب فيه معدّل نقل النظام إلى الصفر لأن النظام يتأزّم، ولكننا نريد باستخدام مصطلحات الشبكات نظامًا مستقرًا stable تستمر فيه الرزم بالمرور عبر الشبكة، حتى عندما تعمل الشبكة تحت عبءٍ ثقيل، وإذا كانت الآلية غير مستقرة؛ فقد تتعرض الشبكة إلىانهيار الازدحام congestion collapse. تخصيص الموارد العادل لا يُعَد الاستخدام الفعال لموارد الشبكة المعيار الوحيد للحكم على مخطط تخصيص الموارد، إذ يجب علينا أيضًا أن ننظر في مسألة العدل، ومع ذلك فإننا ندخل بسرعةٍ في وضعٍ غير مفهوم عندما نحاول تحديد ما يشكّل بالضبط تخصيصًا عادلًا للموارد، حيث يوفر مخطط تخصيص الموارد القائم على الحجز على سبيل المثال طريقةً واضحةً لخلق ظلمٍ خاضعٍ للسيطرة، وقد تُستخدم في مثل هذا المخطط حجوزاتٌ لتمكين تدفق فيديو من أخذ 1 ميجابت في الثانية عبر رابطٍ ما، بينما يأخذ نقل ملف 10 كيلو بت في الثانية فقط عبر نفس الرابط. في حال عدم وجود معلوماتٍ صريحة، فسنود أن يتلقى كل تدفقٍ حصةً متساويةً من حيز النطاق التراسلي عندما تتشارك عدة تدفقاتٍ رابطًا معينًا. يفترض هذا التعريف أن الحصة العادلة من حيز النطاق التراسلي تعني حصةً متساوية، ولكن قد لا تساوي الحصصُ المتساوية الحصصَ العادلة، حتى في حالة عدم وجود حجوزات. إذًا هل يجب أن ننظر أيضًا إلى طول المسارات التي يجري موازنتها؟ وما هو العدل على سبيل المثال عندما يتنافس تدفقٌ واحد مؤلف من أربع قفزات مع ثلاثة تدفقات ذات قفزةٍ واحدة كما هو موضح في الشكل التالي؟ بافتراض أن هذا العدل يعني المساواة وأن جميع المسارات متساوية الطول، فقد اقترح الباحث في مجال الشبكات "راج جاين" مقياسًا يمكن استخدامه لتحديد مدى عدالة آلية التحكم في الازدحام، حيث يُعرَّف مؤشر العدل لجاين على نحو أنه بافتراض مجموعةٍ من إنتاجيات التدفق التالية (x1, x2, …, xn) المُقاسة بوحدات ملائمة مثل بتات / ثانية؛ فستُسنِد الدالة التالية مؤشر العدل للتدفقات: ينتج عن مؤشر العدل دائمًا رقمٌ بين 0 و1، حيث يمثل 1 أكبر قدرٍ من العدل، ومن أجل فهم الحدس الكامن وراء هذا المقياس سنتأمل الحالة التي تتلقى فيها جميع التدفقات n إنتاجيةً قدرها 1 وحدة من البيانات في الثانية، ويكون مؤشر العدل في هذه الحالة هو: لنفترض الآن أن تدفقًا واحدًا يتلقى إنتاجيةً بقيمة 1 + Δ، فيكون مؤشر العدل هو: لاحظ أن المقام يزيد البسط بمقدار (n−1)Δ2، وبالتالي فإن مؤشر العدل قد انخفض الآن إلى ما دون 1 سواءً كان التدفق الفردي يزداد أو ينقص عن جميع التدفقات الأخرى (Δ موجبة أو سالبة). هناك حالةٌ بسيطة أخرى يجب مراعاتها حيث يتلقى عدد k فقط من n تدفق إنتاجيةً متساوية، ويتلقى n-k مستخدمًا متبقيًا إنتاجيةً صفرية، وفي هذه الحالة ينخفض مؤشر العدل إلى k / n. ترجمة -وبتصرّف- للقسم Issues in Resource Allocation من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: النقل في الوقت الحقيقي باستخدام بروتوكول RTP في الشبكات الحاسوبية تأسيس الشبكات الحاسوبية والتعرف على تطبيقاتها كشف الأخطاء على مستوى البت في الشبكات الحاسوبية