وصل التكرار، لكن حكم انتفاء الفقد لم يصل: RFC 3708

الخلاصة

• قد يثبت إشعار التكرار أن إعادة إرسال بعينها لم تكن لازمة، لكنه لا يثبت أن كل المقاطع في النافذة نفسها وصلت بلا فقد.
• لا يجيز RFC 3708 استنتاج إمكان التراجع عن تغيير التحكم في الازدحام إلا بعد تأكيد كل الوحدات المعاد إرسالها في النافذة السابقة ووَسْمها كمكررة، ما لم تُفعّل إحدى حالات الإيقاف.

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

هذا هو الفارق الذي يتمحور حوله RFC 3708، وهو مذكرة تجريبية نُشرت في فبراير 2004. يشرح طرقاً متحفظة لاستخدام إشعارات التكرار: DSACK في TCP وإشعارات أرقام تسلسل الإرسال المكررة (TSN) في SCTP. ويفصل بين استعمالين. يمكن للمكدس عدّ الإشعارات لأغراض المراقبة أو المحاسبة. أما إذا أراد المرسِل التراجع عن تغييرات التحكم في الازدحام، فعليه استخدام خوارزمية التمييز الأكثر تشدداً.

تتحقق الخوارزمية أولاً مما إذا كان نطاق التسلسل أو TSN المُبلّغ عنه قد أُعيد إرساله. إذا تكرر الإرسال أكثر من مرة في النافذة نفسها، يتوقف المعالج ولا تُستعد حالة الازدحام السابقة. وإذا لم يُعِد المرسِل إرسال الوحدة قط، فقد يعني الإشعار أن الشبكة نفسها نسخت الحزمة. عندها يطلب RFC 3708 وقف استخدام الخوارزمية حتى نهاية الاتصال، لأن الإشعارات التالية تصبح أصعب إسناداً إلى إعادة إرسال غير لازمة من المرسِل.

حتى الإشعار المطابق لإعادة إرسال لا يكفي. يفحص المرسِل كل مقطع أو قطعة أُعيد إرسالها في نافذة البيانات السابقة. ولا يخلص إلى أن جميع الإعادات كانت زائدة وأن النافذة خلت من الفقد إلا إذا تأكدت كل وحدة ووُسِمت كمكررة. وإذا بقيت إعادة إرسال واحدة بلا هذا الوسم، فلا يتيح الإشعار استنتاجاً. وهناك حاجز آخر عند خلو سجل SACK في TCP وبدء DSACK عند SND.UNA؛ فهذا نمط ينسجم مع ضياع نافذة كاملة من ACK، وفيه يظل خفض معدل الإرسال هو الخيار المتحفظ.

تحتاج الطريقة إلى حفظ حالة إضافية: إلى جانب معلومات استعادة SACK المعتادة، تتبع المنظومة أرقام التسلسل أو TSN التي أُكدت بوصفها مكررة. وهذا يتيح استدلالاً محدود النطاق، لا يقيناً بشأن صدق المستقبِل أو جميع أحداث المسار. ويحذر قسم الأمان في RFC 3708 من أن مستقبِلاً قد يصف بيانات وصلت خارج الترتيب بأنها مكررة أثناء فقد حقيقي، فيدفع المرسِل إلى تعديل خطِر لحالة الازدحام.

يحدد RFC 2883 طريقة ترميز المستقبِل للبيانات المكررة في كتل D-SACK، لكنه لا يفرض على المرسِل استجابة معينة. أما RFC 3522 فيستخدم دليلاً مختلفاً: يمكن لخوارزمية Eifel أن تكتشف الإعادة الزائدة أسرع عبر طوابع TCP الزمنية، مقابل تضمين خيار Timestamp في كل حزمة. طريقة RFC 3708 أبطأ، لكنها تفصل سؤالين: هل كانت إعادة محددة زائدة؟ وهل تسمح الأدلة بإعلان النافذة كلها خالية من الفقد؟ ولا تحدد المذكرة ما ينبغي فعله بعد الاكتشاف.

المصادر: RFC 3708، حالة RFC 3708، RFC 2883، RFC 3517، RFC 3522، RFC 2960، RFC 4960.