لامینار چیست؟
Laminar یک چارچوب جدید برای کنترل تراکم TCP است که زمانبندی انتقال را که دقیقاً زمان ارسال داده‌ها را تعیین می‌کند، از کنترل ازدحام خالص که مقدار کل داده ارسال شده در طول هر RTT را تعیین می‌کند، جدا می‌کند.
الگوریتم پیش‌فرض برای زمانبندی انتقال، اجرای دقیق اصل حفاظت از بسته ون جاکوبسون [Jacobson88] است. داده هایی که به گیرنده می رسند باعث ACK می شوند که به نوبه خود باعث می شود فرستنده مقداری معادل از داده را به شبکه ارسال کند. متغیر حالت اولیه به طور ضمنی در مقدار داده ها و ACK های در حال گردش در شبکه است. این حالت از طریق یک برآوردگر () tcp_packets_in_flight بهبود یافته (معروف به total_pipe) مشاهده می شود. total_pipe بر اساس "pipe" است که در RFC 3517 توضیح داده شده است، اما همچنین شامل مقدار داده های گزارش شده توسط ACK فعلی و ارسال های معلق است که کنترل تراکم را پشت سر گذاشته اند اما منتظر رویدادهای دیگری مانند TSO هستند.
یک متغیر جدید، CCwin، متغیر حالت کنترل تراکم اولیه است. الگوریتم های کنترل تراکم CCwin را برای تنظیم سطح تراکم کلی در طول مسیر تنظیم می کنند. اگرچه CCwin شبیه cwnd است، اما cwnd بیش از حد بارگذاری می شود و توسط الگوریتم های متعدد (مانند سرکوب انفجار) با اهداف متفاوت و گاهی متناقض استفاده می شود.
هر زمان که total_pipe با CCwin متفاوت باشد، الگوریتم زمانبندی انتقال کمی تعداد بخش‌های ارسال شده در پاسخ به هر ACK را تنظیم می‌کند. شروع آهسته و کاهش نرخ متناسب [PRR] (جایگزینی برای نصف کردن نرخ) هر دو در الگوریتم زمانبندی انتقال تعبیه شده اند.
مزیت اصلی چارچوب Laminar این است که با پارتیشن بندی کنترل تراکم و زمان بندی انتقال به زیرسیستم های جداگانه، هر کدام در معرض محدودیت های طراحی بسیار ساده تری قرار می گیرند و توسعه بسیاری از الگوریتم های جدید را که با سازماندهی قبلی کد امکان پذیر نیستند، آسان تر می کند.
چارچوب Laminar فلسفه طراحی زیربنایی کنترل تراکم TCP را تغییر می دهد و به طور بالقوه پیامدهای گسترده ای فراتر از خود پچ دارد. این وصله در نظر گرفته شده است تا به افراد اجازه دهد تا کد را آزمایش کنند، نظر بدهند و به کشف موارد گوشه ای که ممکن است نادیده گرفته شده باشد کمک کند. علاوه بر این، وصله ناقص است به این معنا که تعدادی از الگوریتم‌ها هنوز وجود ندارند، به‌ویژه: الگوریتم‌های کنترل تراکم به غیر از CUBIC و Reno. اعتبار سنجی cwnd; معیارهای مقصد؛ و غیره. واقعا عالی خواهد بود اگر مردم بتوانند به بازسازی برخی از این الگوریتم های دیگر کمک کنند.
چارچوب Laminar و انگیزه آن به طور کامل در یک پیش نویس اینترنتی، draft-mathis-tcpm-tcp-laminar توضیح داده شده است.
لطفا نظرات و پیشنهادات خود را به mattmathis@google.com ارسال کنید.
این پروژه بخشی از تلاش‌های Google برای سریع‌تر کردن وب از طریق بهبود پروتکل است.
یادداشت های اجرایی
Laminar در اصل در 3 تابع (tcp_input.c) پیاده سازی می شود:
Tcp_cong_avoid() و tcp_mult_decr() کنترل تراکم AIMD را با استفاده از متغیر حالت CCwin انجام می دهند. به جز undo، این دو تابع تنها مکان هایی هستند که CCwin تغییر می کند. (هر دو تابع از کنترل کننده های خاص ماژول تراکم فراخوانی می کنند).
Tcp_laminar_schedule() تعیین می کند که چه مقدار داده در پاسخ به هر ACK ارسال شود. این برنامه حفاظت از بسته Van Jacobson را پیاده سازی می کند، که کمی بالا یا پایین تنظیم می شود تا tcp_packets_in_flight() به CCwin همگرا شود.
تغییرات مهمی در برآوردگر ()tcp_packets_in_flight وجود دارد تا آن را در اکثر رویدادهای پروتکل ثابت کند. توقف برنامه ها، تنظیمات در tcp_laminar_schedule()، و از دست دادن بسته های واقعی، tcp_packets_in_flight را تغییر می دهند. پردازش ACK، TSO و بسیاری از رویدادهای دیگر چنین نیستند. توجه داشته باشید که وقتی تلفات وجود داشته باشد، تعداد واقعی بسته‌ها در پرواز بلافاصله تغییر می‌کند، اما در برآوردگر tcp_packets_in_flight() منعکس نمی‌شود تا زمانی که دستگاه ارسال مجدد آنها را به‌عنوان از دست رفته علامت‌گذاری کند و آنها را افزایش دهد lost_out.
پچ را دریافت کنید
این وصله در برابر net-next Dave Miller است و به طور خالص برای 3.5-rc2 اعمال می شود.
نکته: ماژول‌های کنترل تراکم دیگر که Reno و CUBIC به‌روزرسانی نشده‌اند و کامپایل نمی‌شوند. اگر پیکربندی شما ماژول‌های کنترل تراکم دیگری مانند vegas، مقیاس‌پذیر، پرسرعت و غیره را می‌سازد، ابتدا باید غیرفعال شوند.