الخلاصة

  • جعل RFC 3448 المستقبل يبلغ عن معدل الوصول ومعدل أحداث الفقد والتوقيت، بينما ظل المرسل يقيس RTT ويحسب معدلاً مقارباً لسلوك TCP.
  • بقيت X_recv وحدّ الزيادة وجدولة الحزم ومؤقت غياب التغذية قيوداً مستقلة؛ ولم يثبت المسار السلس سعة متاحة أو عدالة دقيقة أو وصولاً إلى التطبيق.

السلاسة لم تلغ واجب التراجع

كانت تغيرات نافذة TCP مناسبة لنقل الملفات، لكنها قد تكون حادة للصوت والبث. لذلك عرّف RFC 3448، المنشور في يناير 2003، آلية TFRC كتحكم قائم على المعدل لتدفقات unicast في شبكة أفضل جهد.

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

لم يحدد TFRC نقلاً كاملاً أو موثوقية أو صيغة حزم وحيدة. أمكن إدخاله في RTP أو في التطبيق. يثبت النص وسجل RFC Editor وDatatracker والتاريخ والمراجع والوثائق اللاحقة وبحث التصحيحات سجل المواصفة، لا انتشارها في شبكة بعينها.

حوّل المستقبل الخسائر إلى أحداث

رأى المستقبل أرقام التسلسل وأوقات الوصول والفقد وعلامات ECN. لم يعتبر كل حزمة مفقودة أمراً منفصلاً. جمع الخسائر الواقعة في نحو RTT واحد داخل حدث فقد واحد حتى يقارب رد فعل TCP على نوبة ازدحام.

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

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

قاس المستقبل أيضاً X_recv وأعاد معلومات زمنية. وصف ما وصل مؤخراً، ولم يمنح المرسل حقاً في السعة المستقبلية.

بقيت ثلاثة مكابح عند المرسل

استخرج المرسل RTT من التوقيت المعاد، ثم استخدم المعادلة التي يوضح سياقها RFC 2915. دخل حجم الحزمة وRTT وp وحدّ زمني لإعادة الإرسال في X_calc، وهو تقريب لمعدل TCP Reno.

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

أما المكبح الثالث فكان الزمن: لا يتضاعف المعدل عادة أكثر من مرة في RTT، وتُجدول الحزم بدلاً من دفعها دفعة واحدة. وهكذا احتاج التقرير الصحيح إلى حساب وسقف وإيقاع قبل أن يصير فعلاً.

استطاع مستقبل خبيث أن يقلل الفقد المبلغ أو يضخم الوصول. حدّت قيود المرسل من تأثيره، لكنها لم تصدق روايته تلقائياً.

غياب الرد قلّص السلطة

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

كان الصمت ملتبساً: ربما فُقدت رسالة العودة، أو تعطل الطريق الأمامي، أو توقف المستقبل، أو دخل التطبيق في خمول. لم يدّع RFC 3448 معرفة السبب؛ اختار استجابة محافظة في غياب اليقين.

بقيت المسؤولية لدى من يرسل. قدم المستقبل الدليل، لكنه لم يتحول إلى سلطة أوامر على الشبكة.

تطورت الآلية وبقيت الإيصالات منفصلة

وضع RFC 2914 التحكم في الازدحام ضمن استقرار الإنترنت. وقدّم RFC 2581 وRFC 3390 سياق TCP، بينما قدّم RFC 3550 سياق RTP.

أدخل RFC 4342 TFRC في DCCP CCID 3، وبحث RFC 4828 الحزم الصغيرة، ثم حل RFC 5348 محل RFC 3448. يثبت هذا التطور والمراجعة، لا نجاحاً عاماً.

لم يكن p سبباً، ولا X_recv سعة، ولا X_calc إذناً. ولم يثبت المعدل المختار تمرير الحزم أو فكها أو جودة التجربة. قد يكون الرسم سلساً بينما تكون البيانات قديمة أو النتيجة سيئة.

تفصل طبقات الواقع لدى Heng Lu بين المشاهدة والتجميع والرسالة والحساب والفعل والنتيجة. تفسر أولوية الكود العامل احتفاظ المرسل بضوابط محلية. وتوضح المواصفة الأولية الدنيا حدود الادعاء: تحكم في الازدحام لا موثوقية ولا عقد تطبيق. هذه قراءة تحريرية لاحقة.

ترك RFC 3448 قاعدة مسؤولية: للمراقب أن يبلغ، لكن على الفاعل أن يبرر فعله ويظل قادراً على التراجع.

المصادر