RFC 1363: مئة ملي ثانية لا تكفي لضمان مكالمة فيديو

الخلاصة

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

يبدو الرقم «100 ملي ثانية» حاسماً على استمارة لبدء مكالمة. ثم نسأل: من أين إلى أين؟ استعمل Craig Partridge في RFC 1363، المنشور في سبتمبر 1992، مثالاً مقصوداً: قد تُعد المدة ممتازة بين الولايات المتحدة واليابان، ومخيبة داخل المدينة نفسها. لم يعرض قياساً لاتصالين حقيقيين؛ كان يفحص خلل الحد الأعلى الواحد: فهو يتجاهل اختلاف المسافة وما يترتب عليها من اختلاف تجربة المستخدم بين رحلة عابرة للمحيط واتصال داخل مدينة.

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

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

قبل أن تطلب السرعة، يجب أن تصف ما ستضخه. يبين الطلب معدل الإرسال المستدام وفق دلو الرموز، والذروة، والحجم التقريبي لدفعة مفاجئة. يعطي RFC مثالاً عملياً: تدفق يريد أكثر من 10 ميغابت في الثانية لا يمر عبر خط T1 سعته 1.5 ميغابت في الثانية. كتابة حد تأخير أجمل لا توسع الخط.

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

كلمة «ضمان» احتاجت حقلاً منفصلاً. ميز Quality of Guarantee بين رغبة بلا التزام، وضمان ناقص، وخدمة متوقعة، وضمان ثابت. ذكر Partridge تجارب مؤتمرات لدى IETF كانت وصلة Ethernet الأخيرة فيها قادرة غالباً على أداء مقبول، لكنها قد تمتلئ أثناء التدفق. المسار الذي يمر بها صالح للاستخدام، لكن وصفه بأنه مضمون عند كل قفزة سيكون ادعاءً أكبر من قدرته. تتطلب الخدمة المتوقعة تعاون معدات المسار للسماح بتراجع محدود تحت الحمل؛ أما ضمان يضم جزءاً لا يتعاون فقد ينهار بلا ذلك الحد المتوقع.

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

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

المصادر: RFC 1363؛ السجل الرسمي لـRFC 1363.