| DUALPI2(8) | Linux | DUALPI2(8) |
نام (NAME)
tc-dualpi2 - الگوریتم مدیریت فعال صف کنترلکننده تناسبی-انتگرالی دوصفی (DUALPI2 AQM)
خلاصه دستور (SYNOPSIS)
tc qdisc ... dualpi2
[ limit PACKETS ]
[ memlimit BYTES ]
[ coupling_factor NUMBER ]
[ step_thresh TIME|PACKETS ]
[ min_qlen_step PACKETS ]
[ drop_on_overload | overflow ]
[ drop_enqueue | drop_dequeue ]
[ l4s_ect | any_ect ]
[ classic_protection PERCENTAGE ]
[ max_rtt TIME [ typical_rtt TIME ]]
[ target TIME ]
[ tupdate TIME ]
[ alpha float ]
[ beta float ]
[ split_gso | no_split_gso ]
توضیحات (DESCRIPTION)
الگوریتم DUALPI2 AQM ترکیبی از روش DUALQ Coupled-AQM با یک AQM پایه بر مبنای PI2 است. الگوریتم PI2 AQM (که جزئیات آن در مقاله ذکرشده در بخش منابع آمده است) به نوبه خود هم توسعهیافته و هم سادهشده الگوریتم PIE AQM است. الگوریتم PI2 بسیاری از روشهای ابتکاری (heuristics) در PIE را غیرضروری میسازد، در حالی که قادر است روشهای کنترل ازدحام مقیاسپذیر مانند TCP-Prague را کنترل کند. با استفاده از PI2، هم Reno/Cubic میتوانند بهطور موازی با Prague مورد استفاده قرار گیرند و انصاف در اندازه پنجره (window fairness) حفظ شود. DUALQ تفکیک تاخیر میان جریانهای کمتاخیر Prague و جریانهای Reno/Cubic را که به صف بزرگتری نیاز دارند فراهم میکند. اهداف اصلی طراحی عبارتند از:
- پشتیبانی از L4S (اتلاف پایین، تاخیر پایین و کنترل ازدحام مقیاسپذیر - Low Loss, Low Latency and Scalable congestion control)
- گزینه DualQ جهت تفکیک ترافیک L4S در یک صف با تاخیر پایین (L-queue)، بدون آسیب رساندن به سایر ترافیکهای زمانبندیشده در صف سنتی (C-queue) به دلیل جفتسازی ازدحام (congestion-coupling)
- راهبردهای اضافه بار (overload) با قابلیت پیکربندی
- استفاده از زمان توقف (sojourn time) برای تخمین مطمئن تاخیر صف
- پیادهسازی ساده
- پایداری تضمینشده و پاسخدهی سریع
تنظیم دقیق پارامترهای PI2 (شامل alpha، beta و tupdate) در DualPI2 دشوار است و معمولاً اگر به شکل حدسی یا تجربی تنظیم شوند، نتایج نامطلوبی میدهند. این پارامترها باید با در نظر داشتن یک هدف مشخص و بهصورت مجموعهای هماهنگ محاسبه شوند. DualPI2 دارای مجموعهای از پارامترهای پیشفرض است که برای اینترنت عمومی، جایی که حداکثر زمان رفت و برگشت (RTT) حدود ۱۰۰ میلیثانیه و مقدار معمول RTT حدود ۱۵ میلیثانیه است، قابل استفاده است. اگر استقرار شما با اهداف فوق تفاوت دارد (مثلاً در یک مرکز داده)، استفاده از پارامترهای کمکی max_rtt و typical_rtt (یا target) بهشدت توصیه میشود. این پارامترهای کمکی برای فراهم آوردن پارامترهای بهینه تئوری PI2 (شامل alpha، beta و tupdate) برای آن اهداف به کار میروند و در صورت تمایل میتوانند پایهای برای تنظیم دقیقتر، آزمایش و ارزیابی باشند.
الگوریتم (ALGORITHM)
DUALPI2 برای فراهم کردن اتلاف پایین و تاخیر کم برای ترافیک L4S، بدون آسیب زدن به ترافیک سنتی طراحی شده است. در هر بازه بهروزرسانی، یک احتمال پایه داخلی جدید بر مبنای تاخیر صف محاسبه میشود. احتمال پایه با یک دلتا (تغییرات) بر پایه اختلاف بین تاخیر فعلی صف و تاخیر هدف (target) و همچنین رشد صف در مقایسه با تاخیر صف در طول بازه tupdate قبلی بهروزرسانی میشود. ضریب بهره انتگرالی alpha برای اصلاح تدریجی خطای صف ماندگار مداوم به سمت تاخیر هدفِ تعیینشده توسط کاربر استفاده میشود، در حالی که ضریب بهره تناسبی beta برای جبران سریع تغییرات صف (رشد یا کاهش) به کار میرود.
احتمال پایه بهروزرسانیشده بهعنوان ورودی برای تصمیمگیری درباره علامتگذاری (marking) و دور انداختن (drop) بستهها استفاده میشود. DUALPI2 احتمال محاسبهشده را متناسب با هر یک از دو صف مقیاسبندی میکند. برای صف L(L-queue)، احتمال در coupling_factor ضرب میشود، در حالی که برای صف C(C-queue)، احتمال به توان دو میرسد تا معادله نرخ ریشه دوم در Reno/Cubic جبران شود. شناسه ECT (l4s_ect | any_ect) جهت دستهبندی ترافیک به صفهای مربوطه استفاده میشود.
اگر DUALPI2 AQM اضافهبار را تشخیص دهد (هنگامی که ترافیک غیرپاسخگو بیش از حد ارسال شود)، میتواند تنها با استفاده از drop و بدون توجه به فیلد ECN، ازدحام را اعلام کند، یا در حالت جایگزین احتمال دور انداختن را محدود کرده و اجازه رشد صف را بدهد تا سرانجام overflow رخ دهد (مانند حذف انتهای صف یا taildrop).
جزئیات بیشتر را میتوانید در RFC ذکرشده در زیر بیابید.
پارامترها (PARAMETERS)
- limit PACKETS
- تعداد بستههایی را که میتوان در صف قرار داد محدود میکند. بستههای ورودی به محض رسیدن به این محدودیت دور ریخته (drop) میشوند. این محدودیت میان L-queue و C-queue مشترک است. مقدار پیشفرض 10000 بسته است. این مقدار معادل حدود ۱۲۵ میلیثانیه تاخیر روی یک پیوند 1Gbps است.
- memlimit BYTES
- حداکثر میزان حافظهای را که میتواند استفاده شود محدود میکند. بستههای ورودی به محض رسیدن به این محدودیت حافظه دور ریخته میشوند. این مقدار میان L-queue و C-queue مشترک است. مقدار پیشفرض برابر با 10000 * MTU اینترفیس برحسب بایت است.
- coupling_factor NUMBER
- ضریب نرخ جفتسازی میان Classic و L4S را تعیین میکند. مقدار پیشفرض 2 است.
- l4s_ect|any_ect
- دستهبندیکننده ECT را پیکربندی میکند. بستههایی که مقدار ECT آنها با این گزینه مطابقت داشته باشد به L-queue فرستاده میشوند، جایی که علامتگذاری مقیاسپذیر دریافت میکنند. مقدار پیشفرض l4s_ect است، یعنی شناسه L4S معادل ECT(1). تنظیم این گزینه روی any_ect باعث میشود تمامی بستههایی که فیلد ECN آنها صفر نیست به L-queue فرستاده شوند. این کار امکان سازگاری رو به عقب را با مواردی چون DCTCP فراهم میکند. توجه داشته باشید که DCTCP فقط باید برای ترافیک درون مرکز داده (intra-DC) با RTT بسیار پایین و تاخیر هدف AQM بزرگتر از آن RTTها و جدا از ترافیک اینترنت (حتی در صورت سازگاری با کنترل ازدحام Prague) استفاده شود؛ چرا که DCTCP از تمامی الزامات Prague برای اطمینان از عملکرد مناسب در گستره RTTهای اینترنت پشتیبانی نمیکند.
- step_thresh TIME | PACKETS
- آستانه پلهای (step threshold) را برای L-queue تنظیم میکند. این گزینه باعث میشود بستههایی که زمان ماندگاری یا توقف (sojourn time) آنها از این آستانه فراتر رود، همواره علامتگذاری شوند. این مقدار میتواند با واحدهای زمانی (یعنی us، ms، s) یا برحسب بسته (p، pkt، packet(s)) مشخص شود. اگر مقداری بدون واحد درج شود، زمان (برحسب میکروثانیه، us) در نظر گرفته میشود. در صورت تعریف آستانه برحسب بسته، حتماً GRO را روی اینترفیسهای ورودی غیرفعال کنید. مقدار پیشفرض 1ms است.
- min_qlen_step PACKETS
- بستههای ورودی اضافه شده به L-queue هنگامی که طول صف L-queue از این مقدار فراتر رود، ممکن است آستانه پلهای را اعمال کنند. مقدار پیشفرض 0 بسته است. این بدان معناست که هر بسته قرارگرفته در L-queue که زمان ماندگاری آن از آستانه پلهای فراتر رود، علامتگذاری خواهد شد.
- drop_on_overload | overflow
- راهبرد اضافه بار (overload) را کنترل میکند. گزینه drop_on_overload با دور انداختن بسته در هر دو صف هنگام اضافه بار، تاخیر را در L-queue پایین نگه میدارد. گزینه overflow تاخیر را فدای اجتناب از اتلاف بسته میکند، که سرانجام پس از رسیدن به limit منجر به رفتار حذف انتهای صف (taildrop) میشود. مقدار پیشفرض drop_on_overload است.
- drop_enqueue | drop_dequeue
- مشخص میکند بستهها چه زمانی بر پایه الگوریتم PI علامتگذاری یا دور انداخته شوند. علامتگذاری L4S مبتنی بر step_thresh همواره در زمان خروج از صف (dequeue) انجام میشود. مقدار پیشفرض drop_dequeue است.
- classic_protection PERCENTAGE
- از C-queue در برابر ترافیک غیرپاسخگو در L-queue محافظت میکند. این گزینه حداکثر تاخیر زمانبندی در C-queue را به (100 - PERCENTAGE) برابر بیشتر از تاخیر در L-queue محدود میکند. مقدار پیشفرض 10 است.
- typical_rtt TIME
- max_rtt TIME
- حداکثر زمان رفت و برگشت (RTT) و/یا RTT معمولی ترافیکی را که توسط DUALPI2 کنترل میشود مشخص میکند. این مقادیر با واحدهای زمانی (یعنی us، ms، s) مشخص میشوند. مقداری بدون واحد، برحسب میکروثانیه (us) فرض میشود. اگر هر یک از مقادیر max_rtt یا typical_rtt مشخص نشده باشد، مقدار مفقود از رابطه زیر محاسبه میشود: max_rtt = typical_rtt * 6. اگر هر یک از این پارامترها داده شود، برای محاسبه خودکار مقادیر مناسب برای alpha ،beta ،target و tupdate مطابق با رابطه ضمیمه A.1 در RFC گروه IETF ذکرشده در زیر استفاده خواهد شد تا کنترلی پایدار حاصل شود. در نتیجه، مقادیر مشتقشده جایگزین مقادیر ارائهشده توسط کاربر خواهند شد. محدوده کاری پیشفرض برای qdisc از مقادیر max_rtt = 100ms و typical_rtt = 15ms استفاده میکند که برای کنترل ترافیک اینترنت مناسب است.
- target TIME
- تاخیر مورد انتظار صف را تعیین میکند. مقدار پیشفرض 15 میلیثانیه (ms) است. مقداری بدون واحد، برحسب میکروثانیه (us) در نظر گرفته میشود.
- tupdate TIME
- تواتری را که در آن احتمال حذف بسته سیستم محاسبه میشود تعیین میکند. مقدار پیشفرض 16 میلیثانیه (ms) است. مقداری بدون واحد، برحسب میکروثانیه فرض میشود. این مقدار باید کمتر از یکسوم حداکثر RTT پشتیبانیشده باشد.
- alpha float
- beta float
- ضرایب بهره انتگرالی و تناسبی (alpha و beta) را برحسب هرتز (Hz) برای کنترلکننده PI تنظیم میکند. این مقادیر میتوانند بر مبنای نظریه کنترل محاسبه شوند. مقادیر پیشفرض 0.16 و 3.2 هرتز هستند که کنترلی پایدار را برای RTTهای تا ۱۰۰ میلیثانیه با tupdate برابر ۱۶ میلیثانیه فراهم میکنند. توجه داشته باشید که برخلاف PIE، اینها ضرایب بهره واقعی و بدون مقیاس هستند. در صورت عدم ارائه، در صورتی که یکی یا هر دوی typical_rtt و max_rtt مشخص شده باشند، بهطور خودکار از آنها مشتق خواهند شد.
- split_gso | no_split_gso
- نحوه مدیریت بستههای تجمیعشده (aggregated) را تعیین میکند. یا تجمیع را بهعنوان یک بسته تکی در نظر میگیرد (بنابراین در علامتگذاری و حذف سرنوشت مشترکی دارند) با گزینه no_split_gso، که مقداری تاخیر دم (tail latency) را با مصرف پردازنده (CPU) مبادله میکند؛ یا با هر بسته بهطور جداگانه رفتار میکند (یعنی آنها را تفکیک میکند) با گزینه split_gso تا علامتگذاری/حذف دقیق بستهها را برای کنترل تاخیرهای صفبندی فراهم سازد. مقدار پیشفرض split_gso است.
مثالها (EXAMPLES)
تنظیم DUALPI2 برای اینترنت با پارامترهای پیشفرض:
# sudo tc qdisc add dev eth0 root dualpi2
تنظیم DUALPI2 برای مرکز داده با DCTCP قدیمی با استفاده از ECT(0):
# sudo tc qdisc add dev eth0 root dualpi2 any_ect
فیلترها (FILTERS)
این qdisc میتواند در ترکیب با tc-filter ها استفاده شود. بهطور دقیقتر، فیلترهایی که بستهها را میربایند ("stealing packets") محترم شمرده و همچنین سایر طرحهای دستهبندی را میپذیرد.
- بستههایی که priority/classid آنها برابر با
- 1 تنظیم شده باشد، در کنار ترافیک L4S در L-queue صفبندی میشوند و در نتیجه مشمول احتمال علامتگذاری افزایشیافته (یا دور انداختن در صورت علامتگذاری بهصورت not-ECT) خواهند شد.
- بستههایی که priority/classid آنها برابر با
- 2 تنظیم شده باشد نیز در L-queue صفبندی میشوند، اما در صورت not-ECT بودن هرگز دور انداخته نمیشوند (مگر اینکه qdisc پر شده و در نتیجه به taildrop متوسل شود).
- در نهایت، تمام دیگر شناسهها یا اولویتهای کلاس (classid/priority) به
- C-queue نگاشت میشوند.
همچنین ببینید (SEE ALSO)
منابع (SOURCES)
- سند IETF RFC9332 : https://datatracker.ietf.org/doc/html/rfc9332
- مجموعه مقالات CoNEXT '16 در دوازدهمین کنفرانس بینالمللی فناوریها و آزمایشهای شبکهای نوظهور: "PI2: A Linearized AQM for both Classic and Scalable TCP"
نویسندگان (AUTHORS)
الگوریتم DUALPI2 توسط Koen De Schepper، Olga Albisser، Henrik Steen، Olivier Tilmans و Chia-Yu Chang که نویسندگان این صفحه راهنما نیز هستند پیادهسازی شده است. لطفاً گزارش باگها و اصلاحات را به فهرست پستی توسعه شبکه لینوکس به نشانی <netdev@vger.kernel.org> ارسال کنید.
| 29 Oct 2024 | iproute2 |