الخلاصة

  • اقترح RFC 1016 آلية SQuID: يحتفظ IP في المضيف المرسل بالتأخير D بين مخططات البيانات المتجهة إلى الوجهة نفسها. قيمة D المعتادة صفر، وتُحفظ حالة للوجهات التي أصبح تأخيرها موجباً فقط.
  • في أرقام المثال يبدأ D بعد التحذير عند 75 ميلي ثانية على الأقل، ويزيد 20 ميلي ثانية مع حدث تحذير لاحق، وتُجمع التحذيرات خلال ثانيتين في حدث واحد. ينخفض D ميلي ثانية واحدة بعد كل ثانية مستوفية للشروط مع وجود بيانات للإرسال. جرب المؤلفان الفكرة في محاكاة مكتوبة بلغة C.

قد تملأ شبكة محلية سريعة طابور بوابة قبل أن يتمكن خط بطيء من إخراج ما وصل إليه. وضع W. Prue وJon Postel في RFC 1016 حساباً يكشف حجم الفارق: إذا تراكم ميغابايت واحد أمام خط بسرعة 56 kb/s، انتظر آخر مخطط بيانات أكثر من دقيقتين قبل خروجه. إذا نفدت مساحة الطابور استطاعت البوابة إسقاط مخطط وإرسال ICMP Source Quench إلى المصدر، تطلب خفض الإرسال نحو الوجهة المعنية. كانت الرسالة تقول أين ظهر الضيق؛ بقي مقدار الفرملة سؤالاً مفتوحاً.

سمى المؤلفان جوابهما SQuID، اختصاراً لـSource Quench Introduced Delay. داخل وحدة IP في المضيف المرسل، يمثل D الزمن الفاصل بين مخططي بيانات إلى الوجهة نفسها. القيمة الافتراضية صفر. يحتفظ المضيف بقائمة للوجهات الحديثة التي صار لها تأخير غير صفري. وبينما تنتظر حزمة وجهة مزدحمة، يمكن لحزمة متجهة إلى مكان آخر أن تغادر. لم يكن الازدحام في طريق واحد حكماً على حركة كل الطرق الخارجة من الجهاز.

في صيغة المثال يرتفع D بسرعة ويعود ببطء. عند حدث Source Quench تصبح قيمته الأكبر بين «D الحالي زائد 20 ميلي ثانية» و«75 ميلي ثانية». وصول عدة تحذيرات خلال ثانيتين يعد حدثاً واحداً. قد ترسل البوابة إشعارات كثيرة في دفعة واحدة؛ احتساب كل إشعار فرملة مستقلة يرفع الانتظار أكثر مما يلزم. بعد مرور ثانية مستوفية للشروط مع وجود بيانات تنتظر الإرسال، ينخفض D ميلي ثانية واحدة، ولا يتجاوز الصفر نزولاً. الوجهة التي لم يرسل إليها المضيف شيئاً لا تمحو الساعة تأخيرها تلقائياً وهي ساكنة.

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

للبوابة دور آخر في الاقتراح. في عتباته التوضيحية ترسل Source Quench عندما يبلغ الطابور 70%، مع تمرير مخطط البيانات الذي أثار التحذير. عند 95% تبدأ إسقاط البيانات، وتواصل التحذير حتى ينخفض الطابور دون عتبة 50%. الإشارة المبكرة تترك للمصدر فرصة لتغيير إرسال الحزم التالية قبل الامتلاء. البوابة تعرف ضغط طابورها، والمصدر يملك موعد انطلاق ما لم يرسله بعد.

كتب Prue وPostel محاكاة بلغة C لاختبار علاقة IP وTCP بهذه الآلية. وصل نموذج المسار بين شبكتين محليتين بسرعة 10 Mb/s عبر خط واسع بسرعة 56 kb/s، واستخدم مخططات بيانات من 512 بايت وطوابير ومسارات ثابتة. لم تشمل المحاكاة تجزئة مخططات البيانات أو وظيفة TTL. لاحظ المؤلفان تذبذب الخوارزميات التي اختبروها. رفع D قليلاً ثم خفضه بسرعة أبقى المصدر يضغط على الشبكة حتى تتساقط الحزم. الزيادة الأقوى والتراجع البطيء، مع جمع التحذيرات القصيرة، أعطت سلوكاً أفضل في النموذج.

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

سجلت الوثيقة أيضاً أن كثيراً من تطبيقات TCP لم تكن تتلقى حدث Source Quench محدداً بوضوح من IP وICMP. وضع الاستجابة في IP يجعل تغيير الفاصل بين الإرسالات ممكناً عند المصدر. وأشارت المحاكاة إلى تحسن محتمل في معدل النقل الفعلي عندما تحذر البوابة قبل الإسقاط. تبقى قياسات التشغيل على شبكات حقيقية خطوة أخرى؛ نموذج RFC له مسارات ثابتة وحركة مبسطة. لكن سؤال التصميم الذي طرحه شديد الوضوح: كيف تتحول صيحة «تمهّل» إلى توقيت للحزمة القادمة؟

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