الخلاصة

  • حسبت RFC 3322 زمناً قدره 4,131 مللي ثانية لتسلسل SIP/SDP بافتراض وصلة 9.6 كيلوبت/ثانية وزمن ذهاب وإياب 140 مللي ثانية، ووصفت التقريب نفسه بأنه أولي وخشن.
  • استُعمل الحساب لصياغة متطلبات تصميم SigComp، لا بوصفه قياساً لمستخدم أو دليلاً على نشر التقنية أو ضماناً لمكسب محدد.

مسار بلا جواب

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

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

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

رقم دقيق ناتج من افتراضات محددة

قسمت المعادلة حجم كل رسالة بالبتات على 9,600 بت في الثانية، ثم أضافت 70 مللي ثانية، أي نصف RTT مفترض قدره 140 مللي ثانية. وبعد جمع INVITE والأجوبة المؤقتة وPRACK و200 OK وACK، ظهر المجموع 4,131 مللي ثانية. أضيفت تقديرات أخرى منفصلة لإدارة الجلسة وإنشاء الحامل الراديوي.

لكن RFC 3322 قالت إن تقريب WCDMA «rather crude». لم تدخل في الحساب إعادة الإرسال المحتملة بعد الأخطاء. افترضت وصلة خلوية واحدة، وبسّطت أثر شبكة IP الوسطية، واستعملت أحجاماً نموذجية للرسائل. كما أن المقارنة بين نحو 3.6 ثانية لإعداد GSM و7.9 ثانية لحالة SIP كانت من سياق التحفيز، لا قياساً لنجاح SigComp.

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

المتطلب ليس شهادة مطابقة

صدرت RFC 3322 في يناير/كانون الثاني 2003 بوصفها Informational، ولم تحدد معيار إنترنت. طالبت بأن تعيد عملية فك الضغط رسالة مطابقة بتاً ببت، وأن تتعايش مع ROHC، وأن تسمح بالتوافق مع أطراف لا تستخدم الضغط، وأن تخدم تدفقات مختلفة فوق UDP وTCP.

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

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

تُظهر RFC 3320 وRFC 3485 وRFC 3486 ثم RFC 4077 وRFC 5049 استمرار خط التصميم والتشغيل. لكنها لا تقدم تلقائياً نسبة انتشار أو تحسناً مرصوداً. يحتاج ذلك إلى سجلات تفاوض، وإصدارات تطبيقات، وظروف راديوية، وخط أساس غير مضغوط.

القيمة التاريخية لـ RFC 3322 أنها لم تجعل النموذج سلطة. حدّد النموذج سؤالاً قابلاً للمقارنة، وحددت المتطلبات ما ينبغي اختباره. أما التشغيل والنتيجة فبقيا بحاجة إلى دليل مستقل.

Sources