التحكم المتقدم في الازدحام في الشبكات الحاسوبية باستخدام إدارة الأرتال النشطة

سنشرح في هذا المقال طريقةً متقدمةً في تجنب الازدحام في الشبكات الحاسوبية، والتي تضع قدرًا ضئيلًا من الوظائف الإضافية في الموجّه لمساعدة العقدة النهائية في توقُّع الازدحام، ويشار غالبًا إلى هذا الأسلوب باسم إدارة الأرتال النشطة Active Queue Management أو اختصارًا AQM

إدارة الأرتال النشطة باستخدام آليات DECbit وRED وECN

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

آلية DECbit

لقد طُوِّرت هذه الآلية لاستخدامها في معمارية الشبكة الرقمية Digital Network Architecture أو اختصارًا DNA، وهي شبكةٌ غير متصلة ببروتوكول نقل موجَّهٍ بالاتصال، وبالتالي يمكن أيضًا تطبيق هذه الآلية على بروتوكولي TCP وIP. إن الفكرة هنا هي تقسيم مسؤولية التحكم في الازدحام على نحوٍ متساوٍ بين الموجّهات ونقاط النهاية، بحيث يراقب كل موجهٍ الحِمل الذي يواجهه، ويبلغ العقدَ النهائية صراحةً عندما يكون الازدحام على وشك الحدوث. يُطبَّق هذا الإبلاغ عن طريق ضبط بت ازدحام ثنائي في الرزم التي تتدفق عبر الموجّه، ومن هنا جاء اسم DECbit، ثم ينسخ مضيف الوجهة بت الازدحام هذا في الإشعار ACK الذي يرسله مرةً أخرى إلى المصدر، ويضبط المصدر أخيرًا معدل الإرسال الخاص به لتجنب الازدحام. توضِّح المناقشة التالية هذه الخوارزمية بمزيدٍ من التفصيل، بدءًا بما يحدث في الموجّه.

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

نوجّه الآن انتباهنا إلى جزء المضيف host من الآلية، حيث يسجّل المصدر عدد الرزم الخاصة به التي دفعت الموجّه إلى ضبط بت الازدحام، إذ يحتفظ المصدر بنافذة ازدحام كما في بروتوكول TCP تمامًا، ويراقبها لمعرفة أي نسبةٍ من رزم النافذة الأخيرة نتج عنها ضبط البت، فإذا كان ضبط البت ضمن النسبة الأقل من 50% من الرزم، فإن المصدر يزيد من نافذة الازدحام برزمةٍ واحدة؛ أما إذا كان ضبط بت الازدحام ضمن النسبة التي تساوي أو أكثر من 50% من الرزم الأخيرة للنافذة، فإن المصدر يقلل من نافذة الازدحام إلى 0.875 مرةً من القيمة السابقة. وقد اختيرت القيمة 50% بمثابة عتبةٍ بناءً على التحليل الذي أظهر أنها تتوافق مع قمة منحنى القدرة، واختيرت قاعدة "الزيادة بمقدار 1، والنقصان بمقدار 0.875" لأن مبدأ الزيادة المضافة / النقص المضاعف additive increase/multiplicative decrease يجعل الآلية مستقرة.

آلية الاكتشاف المبكر العشوائي

تُسمَّى الآلية الثانية الكشف المبكر العشوائي random early detection أو اختصارًا RED، وتشبه آلية DECbit من حيث أن كل موجهٍ مبرمَجٌ لمراقبة طول الرتل الخاص به، وإعلام المصدر بضبط نافذة الازدحام عندما يكتشف أن الازدحام وشيك. تختلف آلية RED، والتي اخترعتها سالي فلويد Sally Floyd وفان جاكوبسون Van Jacobson في أوائل التسعينات، عن آلية DECbit باتجاهين رئيسيتين هما:

الأول هو تطبيق آلية RED، بحيث يُعرَف ضمنيًا مصدر الازدحام عن طريق إسقاط إحدى الرزم بدلًا من إرسال رسالة إعلامٍ بالازدحام بصورةٍ صريحة إلى المصدر، فيعرف المصدر بذلك بفعالية من خلال المهلة timeout اللاحقة أو من خلال إشعارٍ ACK مكرّر. لقد صمِّمت آلية RED من أجل استخدامها مع بروتوكول TCP، والذي يكتشف حاليًا الازدحام عن طريق المهلات أو بعض الوسائل الأخرى لاكتشاف فقدان الرزمة مثل الإشعارات المكررة، وتُسقِط البوابةُ الرزمةَ في وقتٍ أبكر مما قد تحتاج إليه والذي يوحي إليه مصطلح "المبكر early" من آلية RED، وذلك لإعلام المصدر بأنه يجب عليه تقليل نافذة الازدحام في وقتٍ أقرب مما هو معتاد، أي يسقط الموجه بضع رزمٍ قبل أن يستهلك مساحة المخزن المؤقت تمامًا، وذلك لإبطاء المصدر على أمل أنه لن يضطر إلى إسقاط الكثير من الرزم لاحقًا.
يتمثل الاختلاف الثاني بين آليتي RED وDECbit في تفاصيل الطريقة التي تقرّر بها آلية RED وقت إسقاط الرزمة والرزمة المُقرر إسقاطها. لنفترض استخدام رتل FIFO، حيث يمكننا أن نقرر إسقاط كل رزمةٍ قادمةٍ مع احتمال حدوث إسقاط كلما تجاوز طولُ الرتل مستوى هذا الإسقاط، بدلًا من الانتظار حتى يصبح الرتل ممتلئًا تمامًا ثم إجباره على إسقاط كل رزمةٍ قادمة -والتي هي سياسة إسقاط الذيل-، وتُسمى هذه الفكرة بالإسقاط المبكر العشوائي RED، حيث تحدد هذه الآلية تفاصيل كيفية مراقبة طول الرتل ومتى تُسقَط الرزمة.

سنشرح آلية RED كما اقترحتها فلويد وجاكوبسون في الأصل في الفقرات الآتية، كما نلاحظ أنه منذ ذلك الحين اقترح المخترعون والباحثون الآخرون عدّة تعديلات، ولكن الأفكار الرئيسية المعروضة أدناه بقيت نفسها، ومعظم عمليات التطبيق الحالية قريبةٌ من الخوارزمية التالية:

أولًا، تحسب آلية RED متوسط طول الرتل باستخدام متوسط تشغيل موزون مشابه للمتوسط المستخدَم في حساب مهلة بروتوكول TCP الأصلي، أي يُحسَب AvgLen كما يلي:

AvgLen = (1 - Weight) x AvgLen + Weight x SampleLen

حيث ‎<0 < Weight <1 وطول العينة SampleLen هو طول الرتل عند إجراء قياسٍ للعينة، ويُقاس طول الرتل في كل مرةٍ تصل رزمةٌ جديدة إلى البوابة في معظم التطبيقات البرمجية، ويمكن حساب طول الرتل ضمن بعض فترات أخذ العينات الثابتة في العتاد.

يعود السبب وراء استخدام متوسط طول الرتل بدلًا من طول الرتل اللحظي instantaneous، إلى أن المتوسط يمثّل بدقةٍ أكبر فكرة الازدحام، ويمكن أن تمتلئ الأرتال بسرعةٍ كبيرة ثم تصبح فارغةً مرةً أخرى بسبب الطبيعة السريعة لحركة مرور الإنترنت. فإذا قضى الرتل معظم وقته فارغًا، فلن يكون استنتاج أن الموجّه مزدحمًا وإعلام المضيفين بضرورة التباطؤ أمرًا مناسبًا، وبالتالي يحاول حسابُ المتوسط الحالي الموزون اكتشافَ الازدحام طويل العمر كما هو موضح في الجزء الأيمن من الشكل التالي، عن طريق تصفية التغييرات قصيرة الأمد في طول الرتل. يمكنك التفكير في المتوسط الحالي على أنه مرشحُ تمرير منخفض low-pass filter، حيث يحدّد Weight ثابت وقت المرشح. سننناقش مسألة كيفية اختيار ثابت الوقت هذا أدناه.

ثانيًا، تحتوي آلية RED على عتبتين لطول الرتل تشغلّان نشاطًا معينًا، هما العتبة الدنيا MinThreshold والعتبة العليا MaxThreshold، وتوازن آلية RED متوسط AvgLen الحالي بهاتين العتبتين عند وصول رزمةٍ إلى البوابة، وفقًا للقواعد التالية:

if AvgLen <= MinThreshold
    queue the packet
if MinThreshold < AvgLen < MaxThreshold
    calculate probability P
    drop the arriving packet with probability P
if MaxThreshold <= AvgLen
    drop the arriving packet

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

على الرغم من أن الشكل السابق يوضح دالة احتمالية الإسقاط بالنسبة للمتوسط AvgLen فقط، إلا أن الموقف في الواقع أعقد، وبُعَد الاحتمال P دالةً لكلٍّ من المتوسط AvgLen والمدة التي مرت منذ إسقاط الرزمة الأخيرة، والتي تُحسَب على النحو التالي:

TempP = MaxP x (AvgLen - MinThreshold) / (MaxThreshold - MinThreshold)
P = TempP/(1 - count x TempP)

متغير TempP هو المتغير الذي رُسِم على المحور y في الشكل السابق، ويتتبّع المتغير count عدد الرزم الواردة حديثًا التي وُضِعت في الرتل ولم تُسقَط، مع وجود المتوسط AvgLen بين العتبتين. يزداد الاحتمالP ببطء مع زيادة المتغير count، مما يزيد من احتمالية حدوث إسقاطٍ مع مرور الوقت منذ حدوث آخر إسقاط، وهذا يجعل الإسقاطات المتقاربة أقل احتمالًا نسبيًا من الإسقاطات المتباعدة على نطاقٍ واسع. لقد أدخل مخترعو آلية RED هذه الخطوة الإضافية في حساب الاحتمال P عندما لاحظوا عدم توزُّع إسقاطات الرزم جيدًا في الوقت المناسب بدونها، ولكنها بدلًا من ذلك تميل إلى الحدوث ضمن عناقيد clusters. وبسبب احتمال وصول الرزم من اتصالٍ معين ضمن رشقات bursts، يُحتمَل أن تتسبب هذه العناقيد من الإسقاطات في حدوث إسقاطاتٍ متعددة في اتصالٍ واحد، وهذا أمرٌ غير مرغوبٍ فيه، نظرًا لأن إسقاطًا واحدًا فقط لكل مرة ذهابًا وإيابًا يكفي لجعل الاتصال يقلل من حجم نافذته، في حين أن الإسقاطات المتعددة قد تعيده إلى البداية البطيئة slow start.

افترض مثلًا أننا ضبطنا قيمة MaxP على 0.02 وهُيِّئ المتغير count بالقيمة صفر، فإذا كان متوسط طول الرتل في منتصف المسافة بين العتبتين، فإن TempP وقيمة P الأولية، ستكونان بمقدار نصف MaxP أو 0.01، ويكون لدى الرزمة القادمة 99 من 100 فرصة للدخول إلى الرتل في هذه المرحلة. سيزداد P ببطء مع كل رزمةٍ متعاقبة لم تُسقَط، ويتضاعف P إلى القيمة 0.02 بحلول الوقت الذي وصلت فيه 50 رزمةٍ دون إسقاط. وستصل P إلى القيمة 1 في حالةٍ غير متوقعة من وصول 99 رزمةٍ دون خسارة، مما يضمن إسقاط الرزمة التالية؛ أما الشيء المهم في هذا الجزء من الخوارزمية، فهو أنه يضمن توزيعًا متساويًا تقريبًا للإسقاطات بمرور الوقت.

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

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

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

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

افترض ضبط العتبتين MinThreshold وMaxThreshold، فإذا كانت حركة المرور متقطّعةً إلى حدٍ ما، فيجب أن تكون العتبة MinThreshold كبيرةً بما يكفي للسماح بإبقاء استخدامية الرابط في مستوى عالٍ ومقبول، ويجب أيضًا أن يكون الفرق بين العتبتين أكبر من الزيادة النموذجية في متوسط طول الرتل المحسوب ضمن وقت RTT واحد. سيبدو أن ضبط العتبة MaxThreshold على ضعف العتبة MinThreshold قاعدةً عامة معقولة، وذلك نظرًا لمزيج حركات المرور على الإنترنت اليوم، كما يجب أن تكون هناك مساحة تخزينٍ فارغة كافية فوق العتبة العليا MaxThreshold لاستيعاب الرشقات الطبيعية التي تحدث في حركة مرور الإنترنت، دون إجبار الموجّه على الدخول في وضع إسقاط الذيل، وذلك لأننا نتوقع أن يتأرجح متوسط طول الرتل بين العتبتين خلال فترات التحميل العالي.

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

بما أن آلية RED تعمل عن طريق إرسال إشاراتٍ إلى تدفقات TCP لإخبارهم بالتباطؤ، فقد تتساءل عما سيحدث إذا أُهمِلت هذه الإشارات، حيث يُطلق على هذا غالبًا مشكلة التدفق غير المُستجيب unresponsive flow، وتستخدم التدفقات غير المستجيبة أكثر من حصتها العادلة من موارد الشبكة، كما يمكن أن تتسبب في انهيارٍ مزدحمٍ congestive collapse إذا كان هناك ما يكفي منها، تمامًا كما في الأيام التي سبقت التحكم في ازدحام بروتوكول TCP. ويمكن أن تساعد بعض الأساليب الموضحة في القسم التالي على حل هذه المشكلة عن طريق عزل أصنافٍ معينة من حركة المرور عن أصنافٍ أخرى، وهناك أيضًا احتمال وجود آلية RED مختلفة قادرة على الإسقاط بصورةٍ أبطأ من التدفقات التي لا تستجيب إلى التلميحات الأولية التي يُرسلها.

إشعار الازدحام الصريح

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

أي يمكن لآلية RED أو أية خوارزمية AQM مناسبة العمل بصورةٍ أفضل إذا وضعت علامةً marks على الرزمة واستمرت في إرسالها على طول طريقها إلى الوجهة، بدلًا من إسقاط رزمة وافتراض أن بروتوكول TCP سيلاحظ في النهاية بسبب وصول ACK مكرّر على سبيل المثال، وقد دُوِّنت هذه الفكرة في التغييرات التي أجريت على ترويسات IP وTCP المعروفة باسم إشعار الازدحام الصريح Explicit Congestion Notification أو اختصارًا ECN؛ كما طُبِّقت هذه الاستجابة الراجعة feedback من خلال معاملة بتّين في حقل TOS ضمن IP على أنهما بتات ECN.

يضبط المصدر بتًا واحدًا للإشارة إلى أنه يستطيع تطبيق ECN، أي أنه قادرٌ على الرد على إشعار الازدحام، وهذا ما يسمى بت ECT اختصارًا لـ ECN-Capable Transport، وتضبط الموجهات البتَ الآخر على طول المسار من طرفٍ إلى طرف عند مواجهة الازدحام، كما أنه يُحسَب بواسطة أي خوارزمية AQM قيد التشغيل، ويُسمى هذا البت CE أي مواجهة الازدحام Congestion Encountered.

يتضمن ECN رايتين flags اختياريتين إلى ترويسة TCP، بالإضافة إلى البتين السابقين في ترويسة IP -اللذين يكون النقل لهما غير معروف-، حيث تصل الراية الأولى ECE (أي ECN-Echo) من المستقبل إلى المرسل الذي تلقّى رزمةً مع ضبط بت CE. وتصل الراية الثانية CWR (أي نافذة الازدحام المُخفَّضة Congestion Window Reduced)، من المرسل إلى المستقبل الذي قلّل من نافذة الازدحام.

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

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