آشنایی با QoS – بخش چهارم (Prioritization - اولویت‌بندی)

با سلام و عرض خسته نباشید خدمت تمامی دنبال کنندگان عزیز نتورک‌باز ، پس یک مدت طولانی ای که حضور نداشتیم ، در ادامه ی پست قبلی درمورد مبحث QoS ، ایندفعه با موضوع Prioritization یا همان اولویت‌بندی در خدمتتون هستیم و با یکسری از الگوریتم های اولیت بندی در سیسکو آشنا خواهیم شد.

الگوریتم زمانبندی Round Robin : یکی از الگوریتم های زمان بندی ای که توسط سوئیچ ها و روتر های سیسکو استفاده میشود ، الگوریتم Round Robin میباشد. اصولا Round Robin دوره ای را به ترتیب در هریک از صف ها طی میکند. در هر دوره به عنوان مثال یک پیام و یا تعداد مشخص‌شده ای از بایت هارا انتخاب و ارسال میکند و به سراغ صف بعدی میرود.

یعنی به این صورت که به عنوان مثال تعدادی بایتهای صف اول برمیدارد و ارسال میکند، تعدادی از بایت های صف دوم و همچنین تعدادی از بایت های صف سوم الی آخر؛ سپس دوباره از اول شروع میکند و این پروسه را تا زمانی ادامه میدهد تا انتقال موارد داخل صف ها کاملا انجام شود.

الگوریتم Round Robin همچنین از مفهومی به نام weighting استفاده میکند (که عموما با نام weighted round robin شناخته میشود). این مفهوم بدین صورت عمل میکند که اجازه میدهد میزان بایت(هایی) که از صفهای مختلف برداشته میشود، برابر نباشند و به یکسری صف ها ، ترجیح و اولویت بیشتری نسبت به بقیه صف ها داده شود. به عنوان مثال ، روتر ها از ابزار محبوبی با نام Class-Based Weighted Fair Queuing ـ (CBWFQ) استفاده میکنند تا برای هر دسته بندی (Class)، حداقل پهنای‌باند لازم را گارانتی و فراهم کنند، با پیکربندی این ابزار، در زمان شلوغی، در هر صورتی به دسته بندی مورد نظر حداقل میزان پهنای باند مشخص شده اختصاص داده میشود.(ممکن است میزان پهنای باند مصرفی از مقدار مشخص شده بیشتر بشود ، اما کمتر از آن نمیشود).

ابزار CBWFQ عملا به مهندسین شبکه اجازه میدهد که میزان درصد (%) مورد نظر خودرا از پهنای باند به هر کلاس اختصاص بدهند. به عنوان مثال همانطور که در شکل زیر میبینید ، راندرابین 20% از پهنای باند را برای صف اول اختصاص داده است (یعنی یکجورایی قول داده است که از کل پهنای باند موجود ، 20% اش مختص به این صف میباشد،حتی در زمانهای شلوغی) و 30% و 50% را به صف دوم و سوم. و بدین صورت داده هارا انتقال میدهد.

Low Latency Queuing

قبلا در پست و قسمت اول این سری آموزشی در بخشی به نام "Voice and Video Applications" درمورد این صحبت کردیم که چرا داده های ویدئویی و صدا نیاز به Low Latency و زمان تاخیر کم (زمان Delay کم ، Jitter کم ، Loss کم) دارند. متاسفانه الگوریتم RR به تنهایی پیشنهاز های مورد نیاز برای انتقال صدا و تصویر را فراهم نمیکند (زمان Delay کم ، Jitter کم ، Loss کم) و راهکار ما اضافه کردن LLQ یا همان Low Latency Queuing به زمانبند (Scheduler) میباشد.

سیستم RR ، تاخیر بسیار زیادی برای بسته های Voice (صدا) بهمراه دارد ، برای اینکه متوجه بشوید چرا ، تصور کنید که یک پکت Voice از راه میرسد و مسیریابی میشود که از طریق فلان interface با سیستم صف‌بندی مشخص شده در تصویر زیر ارسال شود.

حالا بسته Voice بعدی از راه میرسد، همزمان با اینکه RR به سراغ صف دوم (data1) رفته است! حتی با اینکه 50% از پهنای باند به صف Voice اختصاص داده شده است ، اما RR تا زمانی که 3 صف بعدی را پردازش نکند ، آن پکت Voice را ارسال نمیکند ، و این موضوع باعث Delay و Jitter میشود.

راه حل ما که LLQ میباشد، میآید و به scheduler میگوید که یکجورایی برای یکی یا دوتا صف خاص پارتی بازی کند و بسته هایی را که از راه میرسند ،بدون معطلی ارسال کند. به این صف ها special priority queues گفته میشود.

مشکل حل شد! Jitter و Delay بسیار کم میشود.

تصویر زیر ، این منطق را به خوبی شرح میدهد :

ساختار LLQ میزان Delay و Jitter بسیار کم را برای ترافیک فراهم میکند ، اما یک مشکلی اینجا وجود دارد ، به تصویر قبل دقت کنید!

فرض کنید که لینک خروجی ما دارای سرعت X بیت در ثانیه است و میزان پکت های ارسال voice ، از X بیشتر باشند ! RR هیچوقت نمیتواند به صف های دیگر هم رسیدگی کند(به این حالت queue starvation یا گرسنگی گفته میشود).

ممکنه که همین الان به ذهنتون راهکاری رسیده باشد : ایجاد محدودیت در میزان ترافیک مصرفی صف با استفاده از ویژگی ای به نام Policing ، که یکی از مباحث جذاب QoS میباشد و در پست آینده درمورد این بحث صحبت خواهیم کرد.

امیدوارم که برای دوستان مفید واقع شده باشه.

موفق باشید.