الخلاصة

  • يستخدم RACK أزمنة الإرسال وACK/SACK وRTT ونافذة إعادة الترتيب ليصنّف نطاقاً على أنه مفقود؛ ولا يرصد إسقاطاً مادياً.
  • قد يشير DSACK لاحق إلى إعادة إرسال زائفة، لكنه لا يحدد السبب داخل الشبكة.
  • ينبغي أن يحفظ التشغيل مدخلات الاستنتاج وكل نسخة مرسلة، لا أن يحول قرار الاسترداد إلى حقيقة حادث.

الاسترداد قبل اكتمال القصة

يسأل RACK سؤالاً عملياً: هل يكفي وصول بيانات أُرسلت لاحقاً والزمن المنقضي لإعادة نطاق أقدم لم يُؤكد؟ لا يستطيع المرسل انتظار اليقين بلا نهاية، لذلك يضع حداً للغموض.

تشترط RFC 8985 وصول مقطع أُرسل بعد المقطع محل البحث، وبقاء الأقدم من دون وصول بعد RTT المقدر مضافاً إليه هامش إعادة الترتيب. هذا أقوى من مؤقت منفرد، لكنه يظل استنتاجاً لدى المرسل في لحظة بعينها.

يمكن لـECMP أو إصلاح الوصلة اللاسلكية تغيير ترتيب الوصول. وقد تبقى النسخة الأصلية في الطريق حين يوصف نطاقها بأنه مفقود. العلامة تأمر بإصلاح النطاق وفق الخوارزمية، ولا تعني أن جهازاً شاهد الحزمة وهي تُسقط.

ساعة RACK جزء من الدليل

يحفظ RACK أحدث وقت إرسال لكل مقطع، بما في ذلك الإعادات. ويستخدم أحدث مقطع مُرسل ثبت وصوله مرجعاً، مع RTT حديث ونافذة إعادة الترتيب.

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

عند ندرة ACK، يرسل TLP بيانات جديدة أو يعيد المقطع الأعلى تسلسلاً لاستدعاء رد قبل RTO. يمنح الرد RACK مادة للاستنتاج، ولا يرصد الإسقاط مباشرة.

DSACK يغير الحكم اللاحق

تسمح RFC 2883 للمستقبل بالإبلاغ عن مقطع أو نطاق مكرر. بعد الإعادة، لا يثبت DSACK إلا وصول بيانات مكررة. وبربطه بتاريخ المرسل قد يشير إلى أن الإعادة لم تكن لازمة، لكنه لا يحدد أي نسخة وصلت ومتى ولا سبب وصولها.

لذلك توصي RFC 8985 بتوسيع النافذة عندما يشير DSACK إلى إعادة إرسال زائفة. لكنه لا يسمي طابوراً أو راديو أو وصلة أو نفقاً أو عضواً في ECMP؛ يثبت وصول التكرار لا سببه الكامل.

المصادر