قد يستمر الاتصال بعد أن يفقد طريق العودة إلى MPTCP

الخلاصة

• الاتصال الذي تراجع إلى TCP العادي عبر الربط اللانهائي لا يجوز أن يعود إلى MPTCP خلال عمره، حتى لو أصبحت ظروف الشبكة أفضل.
• وجود تدفق فرعي واحد في MPTCP ليس دليلاً على حدوث هذا التراجع؛ والبحث عن MPTCP مجدداً يحتاج إلى اتصال آخر لا يضمن نجاح التفاوض أو سلامة تكرار عمل التطبيق.

قد يكون إعلان استمرار الخدمة صحيحاً، لكنه لا يصف كل ما حدث. ففي إحدى آليات MPTCP يمكن أن تبقى البيانات متدفقة لأن الاتصال تخلى عن التشغيل متعدد المسارات وانتقل إلى TCP العادي. ما أنقذ التدفق الحالي لا يترك بالضرورة وسيلة لإعادة قدرته السابقة داخل الاتصال نفسه.

تضع RFC 8684 هذا الحد عند التراجع باستخدام الربط اللانهائي. بعده تُمنع العودة إلى MPTCP في الاتصال ذاته. المقصود ليس أن الجهاز فقد هذه القدرة إلى الأبد، ولا أن حساب المستخدم أو الشبكة كلها أصبحا مقيدين. القيد يخص الاتصال الذي انتقل إلى هذه الحالة. ظهور عنوان إضافي أو تعافي واجهة لا يلغي الانتقال الذي تم.

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

لماذا لا يتعلق الأمر بعدد المسارات فقط؟

يعرض MPTCP تدفقاً مرتباً من البايتات، ويستخدم تدفقات فرعية من TCP لنقلها. لكل تدفق فرعي فضاء أرقام تسلسلية خاص به، وللاتصال الكامل تسلسل بيانات آخر. تنقل إشارة DSS العلاقة بين الاثنين كي يضع المستقبِل البيانات في موضعها الصحيح من التدفق الكلي، حتى عندما تأتي عبر تدفقات فرعية مختلفة.

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

يغيّر الربط اللانهائي هذه القاعدة. تستخدم الآلية قيمة طول البيانات المحجوزة، وهي صفر، لربط ما تبقى من الاتصال. بعد التراجع يعتمد المرسِل فقط على إقرارات التدفق الفرعي لإفراغ مخزن الإرسال، وينبغي للمستقبِل أن يتوقف عن إرسال Data ACK الخاصة بـ MPTCP. تستمر الحركة عندئذ وفق عمل TCP العادي.

هذا انتقال في كيفية الاحتفاظ بالبيانات وتحريرها، وليس مجرد اختيار مؤقت لمسار واحد من جانب المجدول. يشرح القسمان 3.3 و3.7 من RFC 8684 هذا الحد. لكن أياً من هذه الإقرارات لا يثبت أن التطبيق أتم عملية أعمال. إثبات استلام النقل ليس إثباتاً لنتيجة العملية عند تقرير إعادة تنفيذها.

ليست كل مشكلة سبباً للخروج من MPTCP

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

عند وجود تدفقات فرعية متعددة، قد يؤدي فشل التحقق إلى إغلاق التدفق المتأثر وإعادة إرسال البيانات عبر غيره. لا تحصل بيانات الربط الذي فشل على إقرار بمستوى الاتصال. بهذه الطريقة قد يبقى MPTCP عاملاً على التدفقات الأخرى. اعتبار كل فشل في التحقق تراجعاً للاتصال بأكمله يطمس هذا الفرق.

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

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

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

يمكن أن يحمل الرقم واحد معنيين

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

ولا يزيل الاستعلام عن العناوين هذا الغموض بالضرورة. تناقش RFC 6897 واجهة تطبيقية مجردة، تتضمن طلب تمكين MPTCP قبل إنشاء الاتصال، والاستعلام عن دعمه بعد الإنشاء، ومعرفة عناوين التدفقات الفرعية القائمة. لا تثبت الوثيقة أن نظام تشغيل محدداً اليوم يوفّر الأسماء الرمزية نفسها أو إشعاراً موثوقاً بتراجع لاحق.

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

يوضح سجل RFC 8684 أنها Proposed Standard صدرت في مارس 2020 وحلت محل نسخة MPTCP السابقة. ويصحح التصويب المعتمد مثالاً في TCP Fast Open يتضمن إقرار بيانات مبكراً، ولا يغيّر حظر العودة في القسم 3.7. أما سجل RFC 6897 فيصنفها وثيقة Informational من مارس 2013، ولم يُظهر بحث التصويبات مدخلات مطابقة. هذه أدلة على التصميم وحدوده، وليست قياسات لأجهزة عاملة أو إحصاءات عن حوادث.

الاتصال الآخر شرط، لا وعد

الحاجة إلى اتصال آخر لاستعادة MPTCP استنتاج من منع العودة داخل الاتصال الحالي. لا تعني أن التفاوض المقبل سينجح. فقد تبقى الأجهزة الوسيطة أو ظروف الطريق التي أدت إلى التراجع على حالها. وجود عنوان آخر لا يضمن تدفقاً فرعياً قابلاً للاستخدام.

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

تدعو مناقشة Lu Heng لمشكلة الوكالة إلى ربط سلطة القرار بتحمل نتائجه. ويقدّم نصه عن غاية BTW وصف البنية على الترويج للمواقف. في هذه الحالة، الوصف الدقيق يعترف بما حفظه التراجع، من دون إخفاء القرار الذي تركه معلقاً بشأن استعادة القدرة.