التحكم في الازدحام المعتمد على المساواة وهندسة حركة المرور المعرفة بالبرمجيات

نختم مناقشتنا لجودة الخدمة من خلال العودة إلى التحكم في ازدحام بروتوكول TCP، ولكن هذه المرة في سياق التطبيقات في الوقت الحقيقي. تذكر أن بروتوكول TCP يضبط نافذة ازدحام المرسل وبالتالي معدل الإرسال استجابةً لأحداث الإشعار ACK والمهلة timeout. تتمثل إحدى نقاط القوة في هذا الأسلوب في أنه لا يتطلب التعاون من موجّهات الشبكة، فهي استراتيجيةٌ تعتمد على المضيف فقط. وتكمّل هذه الاستراتيجية آليات جودة الخدمة التي كنا ندرسها لسببين، أولهما امكانية التطبيقات استخدام الحلول المستندة إلى المضيف دون الاعتماد على دعم الموجّه، وثانيًا أنه حتى مع نشر DiffServ بالكامل، فلا يزال من الممكن أن يكون لرتل الموجه زيادةٌ في عدد المشتركين، ونود أن تتفاعل التطبيقات في الوقت الحقيقي بطريقة معقولة في حالة حدوث ذلك.

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

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

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

لقد رأينا نموذجًا مبسطًا من مساواة معدل TCP سابقًا. ويكفي ملاحظة أن المساواة تأخذ هذا النموذج العام:

والذي ينص على أنه لكي تكون صديقًا لبروتوكول TCP، يجب أن يكون معدل الإرسال متناسبًا عكسيًا مع الوقت ذهابًا وإيابًا RTT ومع الجذر التربيعي لمعدل الخسارة ρ. ولبناء آلية للتحكم في الازدحام خارج هذه العلاقة، يجب على المستلم الإبلاغ دوريًا عن معدل الخسارة الذي يواجهه إلى المرسل، فقد يبلّغ عن فشل في تلقي 10% من آخر 100 رزمة على سبيل المثال، ثم يعدّل المرسل معدل الإرسال لأعلى أو لأسفل، بحيث تستمر هذه العلاقة في الصمود. لا يزال الأمر متروكًا للتطبيق للتكيف مع هذه التغييرات في المعدل المتاح، ولكن العديد من تطبيقات الوقت الحقيقي قابلةٌ للتكيف تمامًا.

هندسة حركة المرور المعرفة بالبرمجيات Software-Defined Traffic Engineering

تتمثل المشكلة الشاملة التي يتناولها هذا مقال في كيفية تخصيص حيز النطاق التراسلي للشبكة المتاح لمجموعةٍ من التدفقات من طرفٍ إلى طرف. سواءٌ كان الأمر مُتعلق بالتحكم في ازدحام بروتوكول TCP أو الخدمات المتكاملة أو الخدمات المميزة، وهناك افتراضٌ بأن حيز النطاق التراسلي للشبكة الأساسي المخصَّص ثابت؛ فرابطٌ بسرعة 1 جيجابت في الثانية بين الموقع A والموقع B هو دائمًا رابطٌ بسرعة 1 جيجابت في الثانية، وتركّز الخوارزميات حول أفضل طريقةٍ لمشاركة 1 جيجابت في الثانية بين المستخدمين المتنافسين. ولكن ماذا لو لم يكن الأمر كذلك؟ ماذا لو كان بإمكانك الحصول على سعة إضافية "على الفور" بحيث يجري ترقية الرابط بسرعة 1 جيجابت في الثانية إلى رابطٍ بسرعة 10 جيجابت في الثانية؟ أو ربما يمكنك إضافة رابطٍ جديد بين موقعين غير متصلين من قبل؟

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

ولكن مع ظهور تقنيات مثل DWDM وMPLS الموصوفتين سابقًا، لا يتعين علينا دائمًا وضع المزيد من الألياف، ويمكننا بدلًا من ذلك تشغيل أطوالٍ موجيةٍ إضافية أو إنشاء داراتٍ جديدة بين أي زوج من المواقع. ليس من الواجب ربط هذه المواقع مباشرةً بالألياف، فقد يمر الطول الموجي بين بوسطن وسان فرانسيسكو عبر ROADM في شيكاغو ودنفر على سبيل المثال، ولكن ترتبط بوسطن وسان فرانسيسكو عبر رابطٍ مباشر من منظور مخطط شبكة L2 / L3، ويقلّل ذلك من وقت الوصول التوافرية بصورةٍ كبيرة، ولكن لا تزال إعادة ضبط العتاد تتطلب تدخلًا يدويًا، وبالتالي لا يزال تعريفنا لمصطلح "على الفور" يُقاس بالأيام إن لم يكن بالأسابيع، وهناك أيضًا استمارات طلبٍ يجب ملؤها ضمن ثلاث نسخ.

ولكن كما رأينا مرارًا وتكرارًا، يمكن استخدام البرنامج للتعامل مع المشكلة بمجرد توفير واجهات برمجية مناسبة، ويمكن لمصطلح "على الفور" أن يكون فوريًا حقًا، وهذا هو ما يفعله مزودو الخدمات السحابية بفعالية مع الشبكة الرئيسية Backbone الخاصة المُنشأة لربط مراكز البيانات الخاصة بهم. فعلى سبيل المثال، وصفت Google علنًا شبكة WAN الخاصة المُسماة B4، والتي أنشِأت بالكامل باستخدام مبدلات الصندوق الأبيض وSDN، حيث لا تضيف أو تُسقِط B4 أطوالًا موجيةً من أجل ضبط حيز النطاق التراسلي بين العقد، فهي تبني أنفاقًا من طرفٍ إلى طرف ديناميكيًا باستخدام تقنية تسمى المسارات المتعددة ذات التكلفة المتساوية Equal-Cost Multipath أو اختصارًا ECMP، وهي بديلٌ عن CSPF الموصوفة سابقًا وتوفّر نفس المرونة.

يزوّد برنامج التحكم في هندسة حركة المرور TE بعد ذلك الشبكة وفقًا لاحتياجات أصنافٍ التطبيقات المختلفة. يحدد B4 ثلاثة أصناف من هذا القبيل:

نسخ بيانات المستخدم مثل البريد الإلكتروني والمستندات والصوت / الفيديو إلى مراكز البيانات البعيدة لتحقيق التوافرية.
الوصول إلى التخزين البعيد عن طريق الحسابات التي تعمل عبر مصادر البيانات الموزعة.
دفع البيانات واسعة النطاق لمزامنة الحالة عبر مراكز بيانات متعددة.

تُرتَّب هذه الأصناف حسب زيادة الحجم وتقليل حساسية وقت الاستجابة وتقليل الأولوية الإجمالية، حيث تمثل بيانات المستخدم أقل حجم ضمن B4، والأكثر حساسيةٍ لوقت الاستجابة، وذات الأولوية العليا.

تمكنت Google من خلال مركزية عملية صنع القرار -وهي إحدى مزايا SDN المزعومة-، من زيادة استخدامية الروابط الخاصة بها إلى ما يقرب من 100%، وهذا أفضل بمرتين إلى ثلاث مرات من متوسط الاستخدام الذي يبلغ 30-40% والتي توفرها روابط WAN لها عادةً، وهو أمرٌ ضروري للسماح لهذه الشبكات بالتعامل مع كلٍ من رشقات حركة المرور وفشل رابط أو مبدّل. إذا كان بإمكانك تحديد كيفية تخصيص الموارد مركزيًا عبر الشبكة بالكامل، فمن الممكن تشغيل الشبكة بصورةٍ أقرب إلى أقصى حدٍ من الاستخدامية. ضع في حساباتك أن توفير الروابط في الشبكة يكون لأصناف التطبيقات القاسية coarse-grain، وأنه لا يزال التحكم في ازدحام بروتوكول TCP يعمل على أساس اتصالٍ تلو الآخر، ولا تزال قرارات التوجيه تُتخذ على مخطط B4.

تجدر الإشارة إلى أنه نظرًا لأن B4 عبارة عن شبكة WAN خاصة، فإن Google حرةٌ في تشغيل خوارزمية التحكم في الازدحام الخاصة بها مثل BBR دون الخوف من حدوث ضررٍ غير عادل للخوارزميات الأخرى.

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