الخلاصة

  • في السلوك التقليدي حسب RFC 3168، يواصل المستقبل وضع ECE على الإقرارات بعد رؤية CE، إلى أن يتلقى مقطع بيانات جديداً يحمل CWR.
  • يمكن لملاحظة CE واحدة أن تنتج عدداً كبيراً من حزم ACK المزودة بـECE؛ فهي تحفظ حالة تغذية راجعة ولا تعدّ حوادث مستقلة.
  • تستخدم مرحلة إنشاء الاتصال ECE وCWR أيضاً للتفاوض على القدرة، كما تحد الأنفاق والتجارب اللاحقة من أي إسناد مبني على العدد الخام.

لماذا يظل الصدى مرفوعاً

إذا سجل مسبار ثمانية إقرارات متتالية تحمل ECE، فثمة حقيقة واحدة مباشرة: شوهدت ثماني حزم بهذه الإشارة. لكن وصفها بأنها ثمانية أحداث ازدحام يحتاج إلى دليل آخر. بعد إنشاء الاتصال، يضع المستقبل ECE في الإقرار عندما يستلم بيانات تحمل الرمز Congestion Experienced. وإذا جمع ACK مؤجل عدة مقاطع وكان واحد منها على الأقل يحمل CE، خرج الإقرار مزوداً بـECE.

لا يمحو المستقبل الحالة بعد الرسالة الأولى. بل يواصل ضبط ECE في الإقرارات التالية حتى لو كانت تخص بيانات لاحقة غير معلّمة، ولا يتوقف إلا عند وصول CWR من المرسل. لذلك قد ينعكس أثر علامة واحدة مرات عديدة تبعاً لمعدل البيانات، وسياسة الإقرار، والفقد على طريق العودة، وسرعة استجابة المرسل.

يعالج هذا التصميم احتمالاً عادياً: ربما تضيع أول حزمة ACK. لو كان الصدى وحيداً لاختفى معه إشعار الازدحام. إبقاء ECE مرفوعاً يمنح الرسالة فرصة جديدة. ومن ثم فالوحدة الأدق هي فترة تبدأ برؤية CE، وتستمر بسلسلة ECE، وتنتهي برد CWR؛ وليست مجموع الحزم داخل الفترة.

CWR إيصال الإغلاق

في الخوارزمية التقليدية، يعامل المرسل ECE بوصفه إشارة ازدحام ويخفض نافذته على نحو يشبه استجابته للفقد. لكنه لا يخفض النافذة من جديد مع كل إقرار يكرر ECE. ففي سلسلة خسائر أو علامات CE ضمن نافذة بيانات واحدة، أي في حدود زمن رحلة ذهاب وعودة تقريباً، ينبغي أن يقع الخفض مرة واحدة.

بعد الاستجابة، يضع المرسل CWR في أول مقطع بيانات جديد يرسله. وتنصح RFC 3168 بألا يحمل مقطع معاد الإرسال هذا الرد. عندما يصل المقطع الجديد إلى المستقبل، يغلق حالة ECE، فلا يضيفها إلى إقرارات البيانات اللاحقة الخالية من CE. وتستطيع علامة جديدة فتح فترة أخرى.

إذا ضاع المقطع الجديد الذي يحمل CWR، تبقى ECE ظاهرة ويستطيع إقرار لاحق إعادة الإشعار، وقد ينتج عن ذلك CWR آخر. هذه المتانة هي سبب تعدد الأعلام لا دليلاً على تعدد العلامات. وجود CWR يؤيد أن المرسل استجاب بعد إرسال البيانات المعنية، لكنه لا يثبت وصول إقرار ECE بعينه ولا يحدد الجهاز الذي وضع CE.

عند SYN يتغير معنى التركيب

قبل انتقال البيانات، تنتمي الأعلام إلى قواعد تفاوض مختلفة. يرسل الطرف المبادر SYN مع ECE وCWR معاً طالباً استخدام ECN. ويرد الطرف القادر بـSYN-ACK يحمل ECE من دون CWR. هنا تعلن ECE القدرة ولا تردد ازدحاماً أصاب SYN.

النظام الذي يحذف مرحلة TCP والاتجاه وسائر الأعلام ثم يحتفظ فقط بالقيمة «ECE موجودة» سيخلق حادثاً وهمياً عند كل تفاوض ناجح. كما أن نجاح التفاوض لا يلزم المضيف بوضع رمز ECT في كل حزمة بيانات يرسلها لاحقاً. السياق جزء من الدليل.

هناك أيضاً عدم تماثل في الطريقين. ففي RFC 3168 التقليدية تُرسل إقرارات ACK الصرفة بقيمة Not-ECT. ولذلك تصف سلسلة ECE حالة نتجت من بيانات الطريق الأمامي، ولا تمثل مسحاً مماثلاً لازدحام طريق الإقرار.

لا تعطي الإشارة عنوان الطابور

توضح RFC 7567 أن الإدارة النشطة للطوابير قد تضع علامة ECN بدلاً من الإسقاط في الازدحام الخفيف أو المتوسط، وقد تتصرف قبل امتلاء الطابور. فلا تثبت CE وحدها فيض الذاكرة المؤقتة، أو فقداً فعلياً، أو زمناً محدداً، أو عتبة جهاز بعينه.

وتزيد الأنفاق المسافة بين الإشارة ومكانها. قد لا ترى عقدة داخل النفق إلا الرأس الخارجي فتعدل حقل ECN فيه. تحدد RFC 6040 طريقة جمع الطرفين للحقلين الداخلي والخارجي لنقل المعلومة. يمكن أن تكون ECE عند الوجهة صحيحة من دون أن تكشف موضع إنشاء CE.

وينبغي فصل ذلك أيضاً عن ACK المكرر في RFC 5681. للإقرارات المكررة شروطها، وقد تنشأ من الفقد أو إعادة الترتيب أو النسخ. رقم الإقرار، وتسلسل البيانات، وإعادة الإرسال، وECE، وCWR، والزمن عناصر مستقلة.

وأخيراً، تسمح RFC 8311 بتجارب موثقة تخفف بعض قيود RFC 3168 وتختبر استجابات أو علامات مختلفة. الحالة الموصوفة هنا عقد TCP التقليدي، لا قاعدة شاملة لكل تجربة ECN أو بروتوكول نقل.

المصادر