التحكم المتقدم في الازدحام في الشبكات الحاسوبية من خلال الطرق القائمة على المصدر

سنشرح في هذا المقال طريقةً متقدمةً أخرى للتحكم في ازدحام الشبكات الحاسوبية، وذلك فقط من قِبل المضيفين النهائيين وتُطبَّق في بروتوكول TCP، مما يجعلها بديلًا عن آليات التحكم في الازدحام الموصوفة في مقالات سابقة من نفس السلسلة.

الطرق القائمة على المصدر مثل آليات Vegas وBBR وDCTCP

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

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

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

(CurrentWindow - OldWindow) x (CurrentRTT - OldRTT)

إذا كانت النتيجة موجبةً، فسيقلل المصدر من حجم النافذة إلى الثمن؛ وإذا كانت النتيجة سلبيةً أو 0، فسيزيد المصدر النافذة بمقدار أقصى حجمٍ للرزمة. لاحظ أن النافذة تتغير أثناء كل تعديل، أي أنها تتأرجح حول نقطتها المثلى.

هناك تغييرٌ آخر يُنظَر إليه عندما تقترب الشبكة من الازدحام، وهو تسوية معدل الإرسال، حيث سيستفيد مخططٌ ثالث من هذه الحقيقة، وسيزيد حجمَ النافذة بمقدار رزمةٍ واحدة في كل RTT، كما سيوازن الإنتاجية المُحقَّقة مع الإنتاجية عندما كانت النافذة أصغر برزمةٍ واحدة. إذا كان الاختلاف أقل من نصف الإنتاجية المُحقَّقة عندما كانت رزمةٌ واحدةٌ فقط قيد النقل -كما كان الحال في بداية الاتصال-، فستقلل الخوارزمية النافذة بمقدار رزمةٍ واحدة. يحسُب هذا المخطط الإنتاجية عن طريق قسمة عدد البايتات المُعلّقة في الشبكة على RTT.

آلية TCP Vegas

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

يمكن رؤية الغاية الكامنة وراء خوارزمية Vegas من خلال تتبع بروتوكول TCP القياسي الوارد في الشكل التالي. يتتبع الرسم البياني العلوي الموضح في الشكل التالي نافذة ازدحام الاتصال، حيث يعرض نفس المعلومات الواردة سابقًا في هذا القسم، ويوضح الرسمان البيانيان الأوسط والسفلي معلوماتٍ جديدة، حيث يُظهر الرسم البياني الأوسط متوسط معدل الإرسال كما قِيس عند المصدر، بينما يوضح الرسم البياني السفلي متوسط طول الرتل كما قيس في موجّه عنق الزجاجة المزدحِم، وتجري مزامنة الرسوم البيانية الثلاثة في الوقت المناسب، كما تزداد نافذة الازدحام في الرسم البياني العلوي في الفترة بين 4.5 و6.0 ثوان (في المنطقة المظللة). من المُتوقع أيضًا زيادة الإنتاجية المُراقَبة، ولكنها ستظل ثابتةً (في الرسم البياني الأوسط) بدلًا من ذلك، لأن الإنتاجية لا يمكن أن تزيد عن حيز النطاق التراسلي المتاح، وستؤدي أية زيادةٍ في حجم النافذة فقط بعد ذلك إلى استهلاك الرزم مساحةَ المخزن المؤقت في موجّه عنق الزجاجة (في الرسم البياني السفلي):

تصف استعارةٌ مفيدة الظاهرة الموضحة في الشكل السابق، وهي القيادة على الجليد، فقد يشير عداد السرعة (أو نافذة الازدحام) إلى أنك تسير بسرعة 30 ميلًا في الساعة، ولكن بالنظر من نافذة السيارة ورؤية الناس مارّين بجانبك على الأقدام أو معدل الإرسال المُقاس، فأنت تعلم أنك لا تسير بسرعةٍ أكثر من 5 أميال في الساعة، حيث تمتص إطارات السيارة (مخازن الموجّه المؤقتة) الطاقة الإضافية.

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

أولًا، حدد BaseRTT لتدفقٍ معين ليكون بمثابة وقت RTT الخاص بالرزمة عندما لا يكون التدفق مزدحمًا. تضبط آلية TCP Vegas وقت BaseRTT إلى الحد الأدنى لجميع أوقات الذهاب والإياب المقاسة RTTs؛ وعادةً ما يكون RTT للرزمة الأولى التي يرسلها الاتصال، قبل زيادة أرتال الموجه بسبب حركة المرور الناتجة عن هذا التدفق. إذا افترضنا أننا لا نسبب طفحانًا في الاتصال، فستكون الإنتاجية المتوقعة هي:

ExpectedRate = CongestionWindow / BaseRTT

حيث تُشير CongestionWindow إلى نافذة ازدحام TCP، والتي نفترض أنها تساوي عدد البايتات قيد النقل في هذه المناقشة.

ثانيًا، تحسب آلية TCP Vegas معدل الإرسال الحالي ActualRate من خلال تسجيل وقت إرسال رزمةٍ مميزة، وتسجيل عدد البايتات المُرسَلة بين وقت إرسال هذه الرزمة ووقت استلام الإشعار بها، وحساب عينة RTT للرزمة المميزة عند وصول الإشعار بالاستلام، وقسمة الرقم من البايتات المرسلة على عينة RTT، ويُجرَى هذا الحساب مرةً واحدةً لكل وقت ذهاب وإياب.

ثالثًا، توازن آلية TCP Vegas معدل الإرسال الحالي ActualRate بالمعدل المتوقع ExpectedRate وتضبط النافذة وفقًا لذلك، مع افتراض أن:

 Diff = ExpectedRate - ActualRate

لاحظ أن Diff موجب أو 0 حسب التعريف، نظرًا لأن ActualRate >ExpectedRate يعني أننا بحاجة إلى تغيير BaseRTT إلى أحدث RTT أُخِذت منها عينات. سنحدد أيضًا أن عتبتي α < β، تقابلان تقريبًا وجود القليل جدًا والكثير من البيانات الإضافية في الشبكة على التوالي. تزيد آلية TCP Vegas من نافذة الازدحام خطيًا أثناء RTT التالي عندما يكون Diff< α، وإذا كان Diff> β فستقلل آلية TCP Vegas من نافذة الازدحام خطيًا أثناء RTT التالي، وتترك آلية TCP Vegas نافذة الازدحام دون تغيير عندما يكون α < Diff < β.

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

يتتبع الشكل السابق خوارزمية TCP Vegas لتجنب الازدحام، حيث يتتبع الرسم البياني العلوي نافذة الازدحام، ويُظهر نفس المعلومات الواردة في هذا المقال، ويتتبع الرسم البياني السفلي معدلات الإنتاجية المُتوقعة والفعلية التي تحكم كيفية ضبط نافذة الازدحام. يوضح الرسم البياني السفلي أفضل طريقةٍ لعمل الخوارزمية، حيث يتتبع الخط الملون ExpectedRate، بينما الخط الأسود فيتتبع ActualRate. يُعطي الشريط المظلل العريض المنطقة الواقعة بين العتبتين α وβ؛ فالجزء العلوي من الشريط المظلل بعيدٌ بمقدار α كيلو بايت في الثانية عن ExpectedRate، والجزء السفلي من الشريط المظلل بعيدٌ بمقدارβ كيلو بايت في الثانية عن ExpectedRate. يكون الهدف هنا هو الحفاظ على ActualRate بين هاتين العتبتين ضمن المنطقة المظللة؛ فإذا انخفضت قيمة ActualRate إلى ما دون المنطقة المظللة أي بعيدًا جدًا عن ExpectedRate، فستقلل آلية TCP Vegas نافذة الازدحام لأنها تخشى أن تُخزَّن العديد من الرزم مؤقتًا في الشبكة؛ وكلما تجاوز ActualRate المنطقة المظللة أي اقترب كثيرًا من ExpectedRate، فستزيد آلية TCP Vegas من نافذة الازدحام لأنها تخشى من تقليل استخدامية الشبكة.

بما أن الخوارزمية توازن الفرق بين معدلات الإنتاجية الفعلية والمتوقعة مع العتبتين α وβ، فستُحدَّد هاتان العتبتان بالكيلو بايت في الثانية، ولكن ربما سيكون من الأدق التفكير بهاتين العتبتين من خلال عدد المخازن المؤقتة الإضافية التي يشغلها الاتصال في الشبكة، فإذا كانت α = 30 كيلوبايت في الثانية وβ = 60 كيلوبايت في الثانية عند الاتصال مع وقت BaseRTT يبلغ 100 ميلي ثانية وحجم رزمة يبلغ 1 كيلوبايت على سبيل المثال، فيمكننا التفكير في α على أنها تحدد أن الاتصال يجب أن يَشغُل 3 مخازن مؤقتة إضافية على الأقل في الشبكة، وأن β تحدّد أن الاتصال يجب ألا يشغل أكثر من 6 مخازن مؤقتة إضافية في الشبكة. يعمل ضبط α بالقيمة 1 مخزن مؤقت وβ بقيمة 3 مخازن مؤقتة بصورةٍ جيدة عمليًا.

أخيرًا، ستلاحظ أن آلية TCP Vegas تقلل من نافذة الازدحام خطيًا، وهذا يتعارض ظاهريًا مع القاعدة التي تقول بأن النقص المضاعف multiplicative decrease ضروريٌّ لضمان الاستقرار، وسبب ذلك هو أن آلية TCP Vegas تستخدم نقصًا مضاعفًا عند انتهاء المهلة؛ فالنقص الخطي الموصوف للتو هو نقصٌ مبكرٌ في نافذة الازدحام التي يجب أن تحدث قبل حدوث الازدحام وبداية إسقاط الرزم.

آلية TCP BBR

إن حيز النطاق عنق الزجاجة التراسلي Bottleneck Bandwidth وRTT أو اختصارًا BBR، هي خوارزمية جديدة للتحكم في الازدحام طورها باحثون في Google. حيث تعتمد BBR على التأخير مثل آلية Vegas، مما يعني أنها تحاول اكتشاف نمو المخزن المؤقت لتجنب الازدحام وفقدان الرزم. يستخدم كلٌ من BBR وVegas الحد الأدنى والأقصى من RTT كما حُسِب على مدار فتراتٍ زمنيةٍ معينة، مثل إشارات تحكمٍ رئيسيةٍ لهما.

تقدم BBR أيضًا آليات جديدة لتحسين الأداء، بما في ذلك التحكم بسرعة الرزم packet pacing، والتحقق من حيز النطاق التراسلي، والتحقق من RTT. يباعِد التحكم بسرعة الرزم بين الرزم بناءً على تقدير حيز النطاق التراسلي المتاح، وهذا يزيل الرشقات والأرتال غير الضرورية، مما ينتج عنه تحسُّن بالإشارة الراجعة. تزيد BBR أيضًا معدلها دوريًا، وبالتالي يجب التحقق من حيز النطاق التراسلي المتاح، وبالمثل تخفض BBR معدلها دوريًا، وبالتالي يجب التحقق من وجود حد أدنى جديد من RTT. تحاول آلية التحقق من RTT أن تكون متزامنة ذاتيًا، أي أن تحدُث تحققاتٌ من RTT الخاصة بتدفقات BBR متعددة في نفس الوقت عند وجودها، وهذا يوفر رؤيةً أدق لمسار RTT الفعلي غير المزدحم، والذي يحل إحدى المشكلات الرئيسية المتعلقة بآليات التحكم في الازدحام القائمة على التأخير، وهي الحصول على معرفةٍ دقيقة بمسار RTT غير المزدحم.

تعمل BBR بنشاطٍ وتتطور بسرعة، ولكن ينصب التركيز الرئيسي على العدل، حيث تُظهر بعض التجارب أن تدفقات CUBIC تحصل على حيز نطاقٍ تراسلي أقل بمقدار 100 مرة عند التنافس مع تدفقات BBR على سبيل المثال، وتُظهر التجارب الأخرى أن الظلم بين تدفقات BBR ممكنٌ أيضًا؛ بينما يتمثل التركيز الرئيسي الآخر في تجنب معدلات إعادة الإرسال المرتفعة، حيث يُعاد في بعض الحالات إرسال ما يصل إلى 10% من الرزم.

آلية DCTCP

نختتم بمثالٍ لموقفٍ صُمِّم فيه نوعٌ من خوارزمية التحكم في الازدحام في بروتوكول TCP للعمل بالتنسيق مع آلية ECN ضمن مراكز البيانات السحابية. يُسمى هذا المزيج DCTCP اختصارًا لـ Data Center TCP والذي يُمثّل مركز بيانات TCP، ويُعَد هذا الموقف فريدًا من حيث أن مركز البيانات مستقلٌ بذاته، وبالتالي من الممكن نشر نسخةٍ مخصصة من TCP، وهنا لا نحتاج للقلق بشأن معالجة تدفقات TCP الأخرى بصورةٍ عادلة. تُعَد مراكز البيانات أيضًا فريدةً من نوعها من حيث أنها مبنيةٌ باستخدام مبدّلاتٍ ذات صندوقٍ أبيض ومنخفضة التكلفة low-cost white-box switches، وتُوفَّر المبدلات عادةً دون زيادةٍ في المخازن المؤقتة، لأنه لا داعي للقلق بشأن الأنابيب الطويلة الضخمة long-fat pipes التي تمتد عبر القارة.

تتكيف DCTCP مع ECN عن طريق تقدير نسبة البايتات التي تواجه الازدحام بدلًا من الاكتشاف ببساطة أن الازدحام على وشك الحدوث، ثم تقيس DCTCP بعد ذلك نافذة الازدحام في المضيفين النهائيين بناءً على هذا التقدير. لا تزال خوارزمية TCP القياسية تعمل في حالة فقد الرزمة فعليًا. وقد صُمِّم هذا النهج لتحقيق سماحٍ للرشقات العالية high-burst tolerance، وزمن انتقالٍ منخفض، وإنتاجيةٍ عالية باستخدام مبدلاتٍ سطحية shallow مخزَّنة مؤقتًا.

يتمثل التحدي الرئيسي الذي تواجهه DCTCP في تقدير نسبة البايتات التي تواجه الازدحام، فإذا وصلت رزمةٌ ورأى المبدل أن طول الرتل K أعلى من العتبة، على سبيل المثال:

K > (RTT × C)/7

حيث أن C هو معدل الربط وسيُقاس بالرزمة في الثانية، حيث سيضبط المبدل بت CE في ترويسة IP، وبالتالي تعقيد RED غير إلزامي. يحتفظ المستقبل بعد ذلك بمتغير بولياني boolean لكل تدفق، والذي سنشير إليه بـ SeenCE، ويطبّق آلة الحالة التالية استجابةً لكل رزمة مستلمة:

إذا ضُبِط بت CE وكان SeenCE = False، فاضبط SeenCE على القيمة True وأرسل إشعارًا ACK مباشرةً.
إذا لم يُضبَط بت CE وكان SeenCE = True، فاضبط SeenCE على القيمة False وأرسل إشعارًا ACK مباشرةً.
خلافاً لذلك، تجاهل بت CE.

النتيجة غير الواضحة لحالة "خلافاً لذلك" هي أن المستقبل يستمر في إرسال الإشعارات المتأخرة مرةً واحدة كل n رزمة، سواءٌ ضُبط بت CE أم لا، حيث ثبت أن هذا مهمٌ للحفاظ على الأداء العالي.

سيحسب المرسل في النهاية نسبة البايتات التي واجهت ازدحامًا خلال نافذة المراقبة السابقة التي تُختار عادةً لتكون RTT تقريبًا، على أنها نسبة إجمالي البايتات المرسلة والبايتات المُرسل إشعارٌ بها مع ضبط رايات ECE. توسّع DCTCP نافذة الازدحام بنفس طريقة الخوارزمية القياسية تمامًا، ولكنها تقلل النافذة بما يتناسب مع عدد البايتات التي واجهت الازدحام أثناء نافذة المراقبة الأخيرة.

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