دو سال بعد از آنکه اکساندر گراهامبل مخترع تلفن، آغاز عصر جدید ارتباطات را در روزنامه ها اعلام کرد شخصی به نام Agner Krarup Erlang در یک خانواده روستایی و فقیر متولد شد. مادر erlang برخلاف عقاید خانوادگی که بیان میکرد باید تمام مردان خانواده کشیش مسیحی شوند و زن ها با یک روحانی ازدواج کنند، با یک معلم روستایی ازدواج کرد. حاصل این ازدواج چهار فرزند بود که Agner فرزند دوم این خانواده بود.
خانواده Agner او را اینگونه توصیف کردند:

... او پسر آرام و صلح‌طلبی بود که مطالعه را به بازی با دیگر پسران ترجیح می‌داد. عصرها، او و برادر بزرگ‌ترش اغلب کتابی را با هم می‌خواندند؛ روش معمول آن‌ها این بود که برادرش، فردریک، کتاب را به شیوه‌ی معمول بخواند، در حالی که Agner که روبروی او پشت میز نشسته بود، کتاب را وارونه می‌خواند.
- the life and works of A.K. Erlang

او در دوران دانش آموزی به همراه خواهران و برادرش در مدرسه ای که پدرش معلم بود تحصیل کرد و سپس وقتی برای دانشگاه اقدام کرده بود دو سال مشغول تدریس در مدرسه پدرش شد. سپس در سال 1896توسط دانشگاه copenhagen بورسیه شد. توی دانشگاه ریاضیات خواند و عاشق مثلثات شد. بعد از فارغ التحصیلی در سال 1901 به مدت 7 سال مدرس بود. نتیجه این تدریس ها توانایی فوق العاده او در آموزش بود.
بعد از آن عضو انجمن ریاضیات شد و با ریاضیدانی به نام J.L.W.V. Jensen آشنا شد. بعد آقای jensen آو را به F. Johanssen که مدیر شرکت تلفنی Copenhagen بود معرفی کرد. johanssen کسی بود که احتمالات را در تلفن به کاربرده بود و مشوق Agner در این زمینه بود. سپس این شرکت یک آزمایشگاه با مسئولیت Agner راه انداخت.
آشنایان Agner را شخصی ساکت و شوخ طبع ولی صرفه جو میدانستند. به دلیل این صرفه جویی بود که در آزمایشگاه خود تصمیم گرفت تا اساس و چهار چوب نظریه صف را برای کاربردهای تلفنی بنا کند و تعداد اپراتور ها را برای هر تماس موفق مشخص کند. این اتفاق برای اولین بار در شرکت مخابرات Copenhagen رخ داد. برای اینکار erlang یک سوال مهم پرسید. یک شرکت چه تعداد سوئیچ و اپراتور نیاز دارد؟
برای پاسخ به این سوال او اول نرخ ورود تماس ها را باید بدست می آورد که متوجه شد توزیع poisson دارند. سپس باید مدت زمانی که شخص باید پشت تلفن باشد تا تماسش بر قرار شود را محاسبه کرد که متوجه شد توزیع نمایی دارد. سوال بعدی آن بود که اگر 100 تا اپراتور و 100 تا سوئیچ داشته باشیم احتمال آنکه همه تماس ها بخواهد بر قرار شود چیست؟
مقاله ای با عنوان The Theory of Probability and Telephone Conversations در سال 1909 توسط Agner درباره توزیع poisson تماس های ورودی نوشته شد که اولین مقاله در زمینه نظریه صف بود.

بعد از این مقاله در سال 1917 یک مقاله دیگری به عنوان Solution of Some Problems in the Theory of Probabilities of Significance in Automatic Telephone Exchanges نوشت که این شناخته شده ترین مقاله ایشان برای شبکه های تلفنی سوئیچینگ خودکار است. توی این مقاله توزیع احتمالی زمان انتظار تماس ها و احتمال loss شدن تماس ها را محاسبه کرده بود. بعدها Agner مفهومی به نام statistical equilibrium را معرفی کرد که اساس فرضیات مقالات امروزی در حالت ergodic است (مربوط به ارزیابی کارایی سیستم است). به طور کلی این فرضیات متوسط یک تابع در زمان های مختلف را میتوان بجای متوسط آن در مکان های مختلف به کاربرد.
اما erlang آدم کم حوصله ای بود، برای همین اکثر مقالاتی که مینوشت بسیار کلی نگری داشت و از اثبات ها معمولا خودداری میکرد. برای همین پژوهش های این شخص بعد از مدتی توسط دیگر دانشمندان به اثبات میرسید.

او سال های زیادی با خواهر کوچکترش زندگی میکرد. خواهرش درباره او اینگونه میگوید:

ارلانگ شخصیتی قابل توجه و منحصربه‌فردی داشت. او شخصی مسیحی، صادق و همدل بود و در عین حال، سرشار از طنز و ظرافت طعنه‌آمیز. ظاهراً، ریشِ قرمز و پرپشت و همینطور شیوه‌ی پوشش او، حالتی هنرمندانه به ظاهرش می‌بخشید. بسیار متواضع و بی‌آزار بود و فضای آرام اتاق مطالعه‌اش را به گردهمایی‌های اجتماعی و جشن‌ها ترجیح می‌داد. او هرگز مشروبات الکلی نمی‌نوشید و دخانیات مصرف نمی‌کرد. ارلانگ مردی نیکوکار بود؛ با زندگی ساده‌ای که داشت، توانایی کمک به دیگران را نیز داشت و این کار را تا حد بسیار زیادی انجام می‌داد.
او کتابخانه‌ی بزرگی از کتاب‌ها جمع‌آوری کرده بود که عمدتاً در زمینه‌ی ریاضیات، نجوم و فیزیک بودند، اما به تاریخ، فلسفه و شعر نیز علاقه‌مند بود. دوستانش او را منبعی خوب و سخاوتمند از اطلاعات در موضوعات مختلف می‌دانستند. او به عنوان فردی خیرخواه شناخته می‌شد و نیازمندان اغلب برای کمک به او در آزمایشگاه مراجعه می‌کردند، و او معمولاً به‌صورتی بی‌آزار و بدون جلب توجه به آن‌ها کمک می‌کرد.
- The life and works of A.K. Erlang

بعد از مدت ها Agner عاشق خانمی شده بود که آن خانم با یکی از همکاران Agner ازدواج میکنه. بعد از آن Agner هیچ وقت عاشق کس دیگه ای نشد و دیگر ازدواج نکرد.

آقای Erlang در زمان شبکه های تلفنی یا PSTN یک فیلد آنالیزی تاسیس کرد به نام Telephone Network Analysis که ترافیک های تلفنی شبکه را بررسی میکرد. بیست سال بعد از مرگ Agner یعنی سال 1948 کتابی به یاد ایشان با نام The life and works of A.K. Erlang نوشته شد تا زندگی و دست آورد های این شخص بزرگ در تاریخ ثبت شود.

سی و یک سال بعد از مرگ آقای erlang تلفن های سوچینگ خودکار در دنیا پذیرفته و عرضه شد. دست آوردهای این شخص در شبکه مدرن همچنان استفاده میشود. مقالات نوشته شده ایشان امروزه نیز مورد توجه پژوهشگران قرار گرفته و از مفاهیم آن همچنان استفاده میشود.

به یاد مرد سخاوتمند و تنها Agner Erlang
قبر Agner Erlang و خانواده در Copenhagen دانمارک

خب حالا که با آقای Agner آشنا شدید نوبت به معرفی یکی از با ارزش ترین دست آورد های ایشون در حوزه مدیریت ترافیک میخواییم صحبت کنیم...

توی شبکه از زمان حضرت آدم تا الان :) همیشه یکی از بحث هایی که خیلی مهم بوده هزینه و QoS در شبکه بوده است. منظورم از هزینه چیه؟
الان شرکت های بزرگ مانند Google و AT&T و CISCO دنبال کاهش هزینه یا افزایش بهره وری از شبکه به همراه کاهش هزینه هستند. کلا میخوان از چیزی که سرمایه گذاری میکنند بیشترین سود رو بگیرن. برای اینکار بحث بهینه سازی توی شبکه مطرح میشه. اگر هزینه شبکه یعنی هزینه های نگهداری کاهش پیدا کنه طبیعتا شرکت سرمایه بیشتری برای بهبود QoS کنار میزاره. از طرفی QoS تنها یک پارامتر نیست خودش چندین پارامتر مانند performance، درصد تلفات بسته، زمان رفت و برگشت و... رو شامل میشه که روی کیفیت سرویسی که شرکت ارائه میده تاثیر میگذارد.
حالا همه اینها به کنار بحث دیگه که خیلی مطرح هست مربوط به مقیاس پذیری و درصد خطاست.
امروزه تجارت ها شکل مدرن و مخابراتی به خود گرفته که طبیعتا ترافیک ها هم افزایش پیدا میکنه و چون این ترافیک ها معمولا از یک سرویس استفاده میکنند روی همدیگه اثر میزارن. از طرف دیگه رفتار کاربران هم توی شبکه ها بشدت مهم هست و روی ضریب خطا توی محاسبات تاثیر گزاره.برای همین انتخاب تکنولوژی خیلی مهم هست.
خب همه اینها برای کسی که میخاد یک شبکه راه بندازه چالش هست دیگه. اینا که گفتیم خیلی کم بودن مثلا پارامتر های امنیتی و تحلیل ریسک هم باید به اونها اضافه کنیم. حتی باید compatibility بین پروتکل ها و تکنولوژی های شبکه رو هم بر رسی کنیم. خب اینا همش مسئله است که باید به آنها پرداخت و حل کرد. باید چیکار کنیم؟؟

برای پاسخ دادن به همه این مباحث باید به مباحث طراحی و پیاده سازی شبکه بپردازیم اما برای پاسخ به کنترل و مدیریت ترافیک به همراه مقیاس پذیری شبکه و تحلیل ترافیک شبکه باید از نظریه teleTraffic استفاده کنیم که موضوع این پست هست.
این نظریه میاد به بهینگی شبکه کمک میکنه و همچنین سعی میکنه تا مشکلات QoS را در هر شبکه با هر فناوری حل بکنه. حالا از این تکنیک در SDN ها زیاد استفاده میشه و مدیران شبکه هم نه زیاد ولی از آن استفاده میکنن. اما چیزی که مشخص است این نظریه بر اساس احتمالات و آمار هست بنابراین نیاز به پیش زمینه عمیقی از ریاضیات و ارزیابی کارایی دارد. خروجی حاصل از این آنالیز ها فهمیدن رفتار کاربران با شبکه و پیدا کردن بهینه ترین پیکربندی در شبکه است.

حالا برای درک بهتر بزارید یک مثالی بزنم:
یک شهر کوچک را فرض کنید که دارای 1000 نفر جمعیت است. حالا تمام فامیل های این ها در یک شهر کوچک دیگر هستند. این دو تا شهر هر کدام دارای یک مرکز تلفن هستند که این دو مرکز بطور مستقیم به هم متصل هستند. حال سوال اینجا مطرح میشود که اگر این دو شهر بخواهند با یکدیگر صحبت کنند به چه تعداد خط تلفن نیاز داریم تا این دو مرکز تلفن را به یکدیگر متصل کنیم؟
چیزی که مشخص است اینکه با 1000 تا خط تلفن کار میتونه راه بیافته اما از طرفی هم این روش بهینه نیست و بشدت منابع هدر میره. چون احتمال اینکه همه با هم یک دفعه ارتباط بر قرار کنند خیلی کمه. اگر تعداد خطوط رو یک بگیریم هم به کافی نیست به احتمال بسیار زیادی تماس ها نا موفق میشن. یعنی یکجورایی شرایط رقابتی به وجود میاد. چه کنیم؟
اینجاست که teleTraffic میتونه کمک کند. با صرف نظر از جزئیات روش میتوان پی برد که اگر تعداد خطوط تلفن برابر 64 باشد و بطور میانگین هر نفر در هر ساعت 6 دقیقه صحبت کند آنگاه احتمال موفق بودن تماس ها برابر 99 درصد است. این احتمال اصلا کم نیست.

بزارید یک مثال امروزی بزنم ولی فکر کردنش با شما:
یک سیستم انتقال داده را در نظر بگیرید که طول بسته ها 2400 بیت بوده و سه بسته بطور تصادفی در هر ثانیه وارد سیستم میشود. سوالی که مطرح میشه اینکه 4 خط با سرعت 2400 بیت بر ثانیه بدیم یا یک خط با سرعت 9600 بیت بر ثانیه؟

اینها نمونه سوالاتی هستند که ما را در طراحی شبکه کمک میکنند تا بتونیم بهینه ترین و به صرفه ترین حالت را در نظر بگیریم.
البته این سوالات برای شبکه های نسل سه به قبل بود. الان توی طراحی شبکه و ارزیابی ترافیک، کاربران و مدل های سرویسی که شبکه ارائه میدهد را هم در نظر میگیریم.

زمانی که آقای erlang زمینه های مختلفی برای آنالیز ترافیک ها و رابطه های احتمالی در شبکه ها را بدست آورد به افتخار ایشون هر واحد traffic load را ارلنگ مینامند و با erl نمایش میدهند.
عبارت traffic load یا traffic intencity به مدت زمان بر قراری ارتباط ها در هر واحد زمان است. مثلا فرض کنید که سه تا تماس به مدت زمان 5و10و15 دقیقه در هر ساعت بر قرار میشود. حالا traffic load چند است؟
(5+10+15) / 60 = 0.5 [erl]

حالا اگر traffic load در یک اتصال یا trunck (اتصال فیزیکی) را محاسبه کنیم احتمال مشغول بودن آن trunk است. اگر در گروهی از trunk ها را محاسبه کنیم متوسط تعداد مورد انتظار trunk های مشغول را به ما میدهد.

بریم سراغ مقالات
من چند تا مقاله در این زمینه مطالعه کردم و به نتایجی رسیدم.

با استفاده از تلترافیک میان حد تاخیر شبکه را بدست میارن. اما روش های مختلفی برای تخمین زدن میزان دقیق تاخیر وجود داره. مثلا یک روش تخمین حد تاخیر در شبکه استفاده از fractal teletraffic delay bound است. فرض کن چندین اتصال به سرور وجود داره که میخواییم QoS آن اتصالات رو بهبود دهیم. حال از کجا بفهمیم که QoS برای کی بهتر میشه آیا برای یک اتصال بهتر میشه یا برای همه. توی اغلب مقالات میان QoS کلی شبکه و سیستم را بررسی میکنند نه صرفا یک اتصال. حالا در شبکه هایی که QoS آنها در یک بازه زمانی یکسان و تکراری است (از نظر آماری) میشه از FTDB استفاده کرد.

با تلترافیک یک روش جدید برای NOMA پیشنهاد میکنند. توی شبکه های نسل 4 به قبل از روش OMA استفاده میکردن که تداخل سیگنال وجود ندارد اما توی شبکه های نسل 5 به بعد از NOMA استفاده میکنند. NOMA یک روش دسترسی چندگانه است که اجازه تداخل کنترل شده روی سیگنال ها Non-Orthegonal رو میده. این سیگنال ها نسبت به هم عمود نیستند برای همین تداخل دارن. مزیت NOMA استفاده بهینه بر اساس شرایط کانال و همچنین به تعداد کاربر بیشتری با QoS متفاوت میشه سرویس داد.
از این نظریه توی شبکه های برق و شبکه های نوری و حتی ATM ها نیز استفاده شده که توی این مقال نمی گنجد :)

یکی از مهم و تخصصی ترین کنفرانس ها ITC است. این اولین و قدیمی ترین کنفرانس در حوزه traffic و ارتباطات شبکه است. الان نویسندگان به درخواست این کنفرانس دارن یک کتابی تهیه میکنن به نام 100Most Frequent Errors که 100 اشتباه رایج در ارزیابی ها را بیان میکنه.
اوایل این کنفرانس مباحثی برای مشکلات ترافیکی برای چند رسانه ای ها؛ مدل سازی ترافیک در شبکه های سیار و شبکه های ISDN بود. اما بعدا موضوعاتی مانند کاربرد teletraffic در شبکه های نسل 5 و هوش مصنوعی، ارزیابی شبکه های مجازی، QoE و کاربرد teletraffic در دنیای هوشمند را نیز اضافه کرد.

و یک چیز شوک آور اینکه کنفرانس های دیگه به پای این کنفرانس نمیرسن. یعنی بقیه کنفرانس ها و ژورنال ها بیشتر زمینه ارزیابی کارایی رو شامل میشن. اما ITC صرفا برای ترافیک شبکه و مدل سازی شبکه است.
موارد زیر در زمینه ارزیابی کارایی با تمرکز بیشتر بر روی شبکه خوب هستند:
1. ACM Transactions on Modeling and Performance Evaluation of Computing Systems
2. ACM SIGMETRICS (IMC )
3. ACM SIGCOMM Computer Communication Review

الان که دارم اینو مینویسم اینقدر مطلب جدید توی این حوزه و کاربرد مدل های نظریه جدید توی شبکه یاد گرفتم که نمیتونم اینجا بگم. به مرور زمان و میان پست ها بگم شاید بهتر باشه. ولی خدایی فکرشم نمیکردم که اینقدر نظریه توی مدل و طراحی شبکه داشته باشیم. واقعا دلچسب و زیادی حجم شون نا امید کننده است :)
هرچند اگر بخواییم این مسیر رو ادامه بدیم فکر کنم باید به مسائل ارزیابی کارایی هم اشاره بکنیم.
اینا رو گفتم صرفا درباره نظریه teletraffic اما بنظرم حق مطلب ادا نمیشه. بزارید یکم درباره اشخاص سر شناس توی حوزه ارزیابی شبکه صحبت کنیم. الان شبکه های بی سیم نسل 5 و 6 بسیار مورد توجه هستند و این اشخاص هم دارن روی ارزیابی این شبکه ها کار میکنند.
1. Michela Meo
2. Markus Fiedler
3. Tobias Hossfeld
4. Fabrice Guillemin
5. Michael Menth
6. Dario Rossi
7. Benny Van Houdt

خودم به شخص با Markus Fiedler زیاد حال نکردم چون زمینه پژوهشی اش اصلا برام جالب نیست. این آقا کلا داره روی VR و ارزیابی این برنامه ها کار میکنه.
آقای Benny Van Houdt هم صرفا پژوهش هاش درباره مدل های مارکوی و کمی الگوریتمی است تا شبکه.
آقای Michael Menth به نظرم خیلی شبکه ای هست و خیلی تخصصی روی SDN و امنیت کار میکنه. اما قدیما بیشتر روی SDN کار میکرد نمیدونم کی گولش زده.
خانم Michela Meo هم بنظرم خیلی کارای ارزیابی شبکه اش خوبه من خیلی خوشم اومد. اتفاقا ایشون یک صحبتی درباره این داره که چرا ما باید ارزیابی کارایی رو به دانشجو های شبکه یاد بدیم که حتما بعدا دربارش صحبت میکنم.
چیزی که بشدت جالبه اقلیت اینا حداقل یک مقاله توی زمینه quantum دادن مثلا آقای Fabrice Guillemin یک مقاله درباره الگوریتم مسیریابی توی quantum network ها داده.
بقیه خیلی ارزیابی کارایی کار میکردن تا شبکه برای همین بهشون نمی پردازم.
اما هنوز به محقق مورد علاقم توی شبکه اشاره نکردم. این آقا کسی بود که علاقه من رو برای ورود به دنیای شبکه بیشتر کرد. پژوهش های این شخص رو خیلی دوست دارم بعدا درباره این شخص هم صحبت میکنم.

قبلا گفته بودم که پژوهش هایی که انجام میشه باید از یکی از سه روش زیر ارزایابی بشه:
1. ریاضیات و فرمال
2. شبیه سازی و مدل سازی
3. تجربی و پیاده سازی در دنیای واقعی
توی شبیه سازی چالش های زیادی است یکی از این چالش ها نبود dataset. یعنی داده اولیه ای وجود نداره که روش رو بتونی ارزیابی کنی.
یکی از datasetDB های معروف که میشه بهش مراجعه کرد و توی خیلی از مقالات بهش اشاره شده سایت crawdad.org است. این سایت زیر نظر IEEE-dataport است. حجم دادهاش زیاده و برای استفاده رایگان محققان و پژوهشگران است. تنها باید توی سایت IEEE-dataport ثبت نام کنید و بعدش برید به این لینک. بعد از همه اینها میتونید از سایت دانلود کنید.

البته سایت های دیگه ای هم هستند مثل kaggle، paperwithcode و opendatalab. البته که خود گوگل هم یک انجین جست و جو به نام datasetsearch داره که میتونید استفاده کنید.
این سایت هم بنظرم خیلی جالب اومد. این مخصوص داده های mobility هست. برای پژوهش هایی که تحرک رو هم شامل میشه. البته باید برید گیت هابش تا بتونید استفاده کنید.

ولی خودمونیم ها وقتی نوبت به کد زدن میرسه محقق ها ریکلس میکنن. چندتا Repository دیدم کدهاشون رو ببینی فکر میکنی ناقصه. اصلا جزئیات نداره انگار.

یعنی اگر کد نمیزاشت توی گیت هاب شخصیتش بالا تر بود تازه ما هم ناراحت نمیشدیم.
اکثرا هم اصلا کدر نیستن. کد هاشون رو ببینی یک چیز کثیف با کامنت های چینی نوشتن که میخوای سریع سیستم رو خاموش کنی که ویروسی نشه. بعدشم از خواب بیدارشی
الانم که اینقدر سطح abstraction رو بالا بردن توی کد ها که فکر کنم دو روز دیگه کل شبیه سازی میشه یک خط.
پژوهش هم قدیمیش خوبه

یکی ار بچهای دانشگاه یک ربات تلگرامی ساخته که بر اساس مدل Gemini هست.این دوستمون بصورت شخصی توی فضای ابری بالا آوردتش که بنظرم جالبش میکنه. هنوز درست و حسابی مدلش train نشده.
یکم باهاش کارکنید ببینید منوچهرخان چطوریه :)
@manoochehrKHAN_bot

یادمه زمانیکه داشتم درس ارزیابی کارایی میخوندم استاد این درس معنی likelyhood و probability را یکی در نظر میگرفت. اما من که میرفتم بعد مرجع میخوندم میدیم یک جا نوشته probability یک جای دیگر نوشته likelyhod. بعدشم نرفتم ببینم که این دو تا چه تفاوتی باهم دارن . توی مترجم هم میزدیم کلمات شبیه هم میاورد که اصلا قابل تفکیک نبودن. اما واقعیت این است که این دو کلمه باهم متفاوت هستند. برای فهم بهتر اون یکی از این ویدئو هایی که گذاشتم رو میتونید نگاه کنید:
1. In Statistics, Probability is not Likelihood
2. Maximum Likelihood, clearly explained!!!
3. the most important theory in probability

سلام دوستان
سال نو مبارکتون باشه. ایشالله سال خوبی برای شما و عزیزانتون باشه🌺

میگما خداروشکر دیگه خبری از یک جلو و عقب کردن ساعت نیست که دوباره طنز های مسخره توی اینستا رو ببینیم. 😅😂

این همه پست گداشتیم و حرف از QoS زدیم ولی این QoS چیه؟ خوردنیه؟ تزریق کردینه؟

فیلد شبکه ها کامپیوتری تاریخچه ای پر از چالش و پر بحثی داشتند تا شکل فعلی و پیرشرفته پیدا کنند. یک دوره ای بود که اصلا پژوهشگران سر این که چه پروتکلی مقاوم و چه پروتکلی نسبت به بقیه برتر هست دعوا میکردند که آن زمان معروف شد به دوره protocol wars.
بعد ها پروتکل های مختلفی مطرح شد که سازمان دفاع آمریکا پروتکل TCP/IP یا بهتر بگیم پشته TCP/IP رو مطرح کرد. این روش از بقیه روش ها برای پیاده سازی راحت تر برتری داشت. اما از آنجایی که شبکه اقیانوس پهناوری هست تفاوت نظر و نگرش ها تنها به protocol war منتهی نشد. یکی از پر بحث ترین مباحث شبکه که از زمان حضرت آدم مطرح است بحث QoS یا کیفیت سرویس هست.
همونطور که میدونید ما توی شبکه یک چیزی داریم به عنوان Quality of Service یا QoS. این یک پارامتر در شبکه است. به طور دقیق تر QoS خود مجموعه ای از پارامترها است. پارامترهایی مثل نرخ تلفات بسته، کارایی، تاخیر، گذردهی و... . این پارامتر ها را هم کاربر میتواند متوجه آن شود و هم شبکه. عوامل و functionality های مختلفی در شبکه بر روی هر یک از آنها میتواند اثر گذار باشد. مثلا پروتکل های مسیریابی به علاوه پروتکل های انتقال داده میتواند بر روی تاخیر اطلاعات تاثیر بگذارد.
اما نظر نهایی درباره QoS را بر خلاق QoEمتخصصان شبکه میدهند چون این کار بچه بازی نیست :)
متخصصان شبکه از زمانی که شبکه های نسل 3 آمد سعی داشتند تا کیفیت سرویس را در شبکه مطرح کنند و برای آن راه حلی پیدا کنند. اما این پارامتر به آسانی قابل حل نیست و یک راه حل ندارد زیرا در شرایط مختلف پارامتر ها میتوانند وابسته به هم و در تضاد هم عمل کنند.
راه حل هایی که برای QoS مطرح میشود بر اساس نظریه صف و بر اساس احتمالات است. در نتیجه راه حل کلی برای آن وجود ندارد و وابسته به شرایط و شبکه است.
متخصصان شبکه روش های مختلفی مانند differentiated service، MPLS و integrated service را پیشنهاد دادند که تا یک زمانی خوب بود و کار میکرد اما از یک جایی به بعد سر بار زیاد و مدیریت آن ها سخت میشد. همچنین DS و IS نمیتونست مهندسی ترافیکرا پشتیبانی کند. مهندسی ترافیک یعنی چی؟ مهندسی ترافیک به بهینه سازی عملکرد شبکه ها میپردازد. به طور کلی، این حوزه شامل به کارگیری فناوری و اصول علمی برای اندازه گیری، مدلسازی، توصیف و کنترل ترافیک اینترنت است و از این دانش و تکنیک ها برای دستیابی به اهداف عملکردی مشخص استفاده میشه.
وقتی که TCP/IP به عنوان بهترین گزینه برای رشد شبکه ها در نظر گرفته شد تمام شبکه ها مبتنی بر IP شدند. خب این باعث میشد که خیلی از پروتکل هایی که مبتنی بر IP نبودند از رده خارج شوند یا یک تبدیلی بر روی این بسته ها انجام شود که معمولا از روش encapsulation برای آن استفاده میکنند.
وقتی شبکه ها مبتنی بر IP شد یک ساختار واحد برای بسته ها به وجود آمد. این ساختار باعث شد تا یک سرویسی به نام IS برای فراهم کردن QoS به وجود بیاد. اما این سرویس خالی از مشکل نبود. مشکلاتی که داشت این بود که تنها برای IP بود، سربار بالایی به دلیل پروتکل RSVP داشت و میان دامنه ای نبود. یعنی از یک سیستم نهایی به یک سیستم نهایی دیگر تعریف میشد کاری به تکنولوژی های شبکه نداشت. علاوه بر اینها مشکل دیگری آن این بود که سیاست های مختلفی در شبکه ها ممکن بود وجود داشته باشه ولی این سرویس از آن به خوبی پشتیبانی نمیکرد. کاریم به این نداریم که نمیشد که هزینه برای آن تعریف کرد.
اما دیدند هیچ چیزی مهم تر از پول نیست. بعد از آن گفتند خب چه غلطی بکنیم که این گند رو به خوبی و خوشی جمعش کنیم. حاصل این فکر سرویس DS بود. این سرویس از مفهوم SLA استفاده کرد تا بتونه یک قرار داد مشتری و فراهم کننده بنویسه. اینجوری هر دو طرف متعهد میشدند که چه سرویسی ارائه میکنند و چه هزینه ای باید پرداخت بشه. علاوه بر آن این سرویس یک مفهوم جدیدی رو به وجود آورد به نام PHB یا per-hub behavior . این ویژگی میگفت هر مسیریاب یا سوئیچ در شبکه میتواند رفتار مختلفی با بسته ها داشته باشد. اینجوری کلاس های مختلفی برای بسته ها به وجود آمد که تعداد آنها 14 بود. این سرویس سه نوع کلاس داشت best-effort، Assured و Expedited. کلاس BF همون روش انتقال اینترنت سنتی بود که فقط سعی میکرد بسته را به کاربر برساند طوری که همه کاربران راضی باشند. کلاس AS پارامتر های QoS را در شبکه با کلاس های مختلف تضمین میکرد و قول میداد که آستانه را حتما رعایت کند حتی زمانی که دستگاهی در شبکه خراب میشد. سرویس EX یک چیزی بین BF و AS است که مثلا برای تاخیر یک حداکثری میداد و میگفت به احتمال 99.9 درصد این آستانه را در بسته ها رعایت میکنم. خوبی این کلاس ها این بود که سیاست های مختلف در شبکه ها میتوانست رعایت بشه همچنین در فروش و محاسبه هزینه روش مشخصی میتواند وجود داشته باشد.

پس یعنی گل سر سبد بود؟ خیر این روش مشکل مهندسی ترافیک را حل نکرده بود. همینطور تنها از IP پشتیبانی میکرد.
بعد از آن تکنولوژی ای به نام MPLS آمد که یک اسکی از شبکه های ATM بود. توی شبکه های ATM ما روی بسته ها برچسبی میزدیم که کار همون آدرس رو میکرد. توی MPLS هم مین کار رو میکنیم که بهش label میگن. این label ها کار مسیریابی رو انجام نمیده و کلا فقط forwarding میکنه تا به نقطه ای برسه که یا از دامنه MPLS خارج بشه که در اینصورت مسیریابی IP انجام میشه یا به مقصد برسه و تمام. اما MPLS خوبی ای که داشت این بود که سریع و سبک بود. علاوه بر اون با هر تکنولوژی مثل بسته های IP و بسته های ATML و x.25 کار میکرد. چون کلا encapsulate میکرد. بعد این امکان رو میداد تا بتونیم مسیرهای انتها به انتها تعریف کنیم که بهش میگن e2e. البته مزیت های خیلی زیادی دیگه ای هم داشت که بهش نمپردازم مخصوصا مهندسی ترافیک را خیلی خوب کرده بود. اما بازم خالی از مشکل نبود. مشکلی که داشت توزیع برچسب بود. چجوری اونها lable ها رو به دیگر مسیریاب ها و شبکه ها بر سونیم. برای همین یک پروتکلی ساختن به نام LDP که کارش فقط توزیع برچسب بود. اما یک مسئله دیگه ما باید قبل از توزیع برچسب بسته های LDP رو مسیریابی کنیم. توی شبکه های بزرگ هم این مسیرها همش عوض میشن حالا باید باز پروتکل مسیریابی مثلا OSPFاجرا و باز LDP. برای همین گفتن شاید مهندس باشیم اما چیز که نیستیم خب یک کاری کنیم همین پروتکل های مسیریابی کار توزی برچسب رو هم انجام بدن برای همین یک چیزی اومد به نام OSPF-TE که هم مدریت ترافیک و مشکلات نسخه های قدیمی OSPF رو بهتر کرده بود و هم توزیع برچسب میکرد.
اما این ها همه ماجرا نبود. کلا این مهندس ها رو ول کنی هی میخوان مشکل درست کنن و اون مشکل رو حل کنن.
یک روزی متخصصین شبکه از خواب بیدار شدن و گفتن که آقا همه اینا اوکی شد اما چجوری شبکه رو مدیریت کنیم و بهترین سیاست ها رو روی شبکه ها اعمال کنیم تا این پارامتر ها را به بهینه ترین حالت در شبکه داشته باشیم. اینجوری شد یک تکنولوژی به وجود آمد به نام SDN یا نسخه اینترنتی یا شبکه wan آن به نام SD-WAN.

البته QoS یک تاریخچه قدیمی تر و پر از جزر و مد داشته که من اینجا یک خلاصه مفید از مطالب مهمش گفتم.
از انجایی که SDN یک مبحثی هست که توجه زیادی به اون شده و مورد علاقه خیلی هاست درباره آن به صورت جداگانه و در آینده صحبت میکنم

#دل_نوشته
بچه های ارشد امیرکبیر باید تا آخر ماه دوم ترم دوم پروپوزالشون رو معرفی کنن و ازش دفاع کنن. تنها هم رشته شبکه و معماری هست که دفاع پروپوزال داره.
من تا موقع پروپوزال هیچ ایده ای از دفاع کردن نداشتم. اصلا نمیدونستم باید چیکار کنم. به ما گفته بودن برید مقاله بخونید و عنوان های بروز و مورد علاقه تون رو پیدا کنید به عنوان پروپوزال بدین. منم اون موقع داشتم دوران سختی رو سپری میکردم. خیلی دوستا داشتم یک کار ترکیبی از پهپاد و SDN توی شبکه های نسل 6 انجام بدم. یا اینکه بیام یک framework جدید برای aerial integration بدم. یا حتی بیام روی مسائل کنترل ازدحام و slicing شبکه کار کنم.
مقاله های مختلف و زیادی رو میخوندم. از طرف دیگه باید کاری میکردم که اگر خواستم اپلای کنم به مشکل نخورم. همینطور بتونم مقاله رو تا تابستون سال بعدش جمع کنم. بچه های سال بالایی هم توصیه میکردن حتما عنوانی رو انتخاب کن که کد شبیه سازی داشته باشه.
چند روزی گذشت و من یک موضوعی رو خواستم شروع کنم با استفاده از پهپاد ها و HAPS یک کاری بکنم اما یادم نمیاد دقیق چه کاری میخواستم بکنم.
بعد از صحبت با استاد صبایی موافقت ایشون رو گرفتم و فرداش با محمد حسین صحبت کردم. گفت حاجی از پهپاد و کلمه drone تا میتونی فرار کن چون ممکنه بعدا توی اپلای به مشکل بخوری. هعیییی ...
باز شروع کردم به گشتن و پیدا کردن عنوان. رفتیم با بچه های سال بالایی یک چایی خوردیم و درباره کارشون باهاشون صحبت کردم تا ببینم دارن چه کارهایی رو پیش میبرن. شاید منم جذب عنوانشون شدم.
10 روز مونده بود به تعیین پروپوزال و رفتم پیش استاد خرسندی. گفتم استاد همچین موضوعی هست و من نتونستم یک عنوان خوب پیدا کنم. استاد گفت برو پیگیر کار آقای اعتدادی شو که داره زمانبندی کار میکنه فقط کاری که تو باید بکنی اینکه مسئله رو پویا و تحرک گره ها رو در نظر بگیری. من هم گفتم اوکی و کار رو شروع کردم. خوشحال از اینکه بالاخره یک عنوانی دارم و یک قدم جلو رفتم.
کلا یک هفته تا روز دفاع پروپوزال مونده بود. من که اصلا نمیدونستم که زمانبندی چیه رفتم همینجوری مقاله های 2022 به بعد رو دانلود میکردم و میخوندم. فکر کنم 54 تا مقاله رو دانلود کردم و همرو خوندم تا ببینم اصلا مسئله چیه و چه باید کرد. زمانبندی هم بی در و پیکر هست و فرق بین زمانبندی وظایف با منابع رو نمیتونستم تشخیص بدم.
روز دفاع دوتا استاد از رشته معماری برای من آوردن به عنوان داور که باید این دوتا عزیز رو قانع میکردم که بله آقا کار من خوبه و میشه روش کار کرد. خداروشکر اون شب به خیر گذشت.

حالا چرا اینا رو گفتم ؟
چند روز پیش داشتم با بچهای ورودی جدید صحبت میکردم و راهنماییشون میکردم و دلداری میدادم شون که بگم آقا پروپوزال همچین اهریمنی هم که فکر میکنید نیست. استادا میدونن که تازه کارید و دست نوازش میکشن بر سرتون. البته بعضی ها هم نوازش شون یکم محکمه. ولی از قدیم گفتم چوب استاد گله هر کی نخوره خله :) مثلا الکی
حالا امیدوارم این حرفا بتونه کمکی به کسایی باشه که الان توی همچین وضعیتی هستن. کلا زندگی سخت و پر از مشکلات و پستی و بلندی هاست. اگر بخواییم احیا بگیریم و ذکر مصیبت بگیم که کاری از پیش نمیره باید ادامه داد. منم توی روزای سخت زندگیم داشتم پروپوزال و عنوان پیدا میکردم. الان به خودم نگاه میکنم میبینم چه مسیر طولانی رو اومدم نباید شرمنده خودم و مهدی قدیمی بشم.

شبکه های سنتی هیچ عامل هوشمندی نداشتند و صرفا یکسری دستگاه بودند که الگوریتم های مشخصی را پیاده میکردند که قابلیت تنظیم پارامتر بر روی آن ها را سخت میکرد.
از آنجایی که شبکه های سنتی مدیریت بسیار پیچیده ای داشتند و مهندسی ترافیک در ان ها لحاظ نمیشد تصمیم بر ارائه یک راه حل کارآمد و مفید جهت حل این مشکل در شبکه های نسل بعدی شد. اسم این راه حل SDN یا Software-defined network بود. اما تنها دلیل استفاده از SDN مدیریت بهتر شبکه نیست. SDN قابلیت های دیگری مانند: مهندسی ترافیک، مدیریت QoS، بهینه سازی کاربرد های شبکه، هوشمند سازی شبکه (استفاده از هوش مصنوعی)، کاهش سربار مدیریتی نسبت به شبکه های سنتی، پشتیبانی از تکنولوژی های مجازی سازی مثل NFVها را به همراه دارد.
اما SDN چیست؟ در سال 2004 مقاله ای تحت عنوان the soft router architecture منتشر شد که در آن کار گروه IETF توانست یک چهارچوبی برای جداسازی صفحه کنترل از داده پیدا کند. از طرف دیگر در دانشگاه stanford دانشجو ها داشتند روی یک پروژه برای پیاده سازی نرم افزاری سوئیچی کار میکردند که حاصل آن یک پروتکل جدید به نام openflow بود. این پروتکل اساس شبکه های مبتنی بر SDN شد. در همان سالی که openflow معرفی شد یک سیستم عامل مخصوص شبکه به نام NOX هم اومد که از این پروتکل و SDN پشتیبانی میکرد. در نهایت در سال 2011 یک سازمانی به نام ONF صرفا برای توسعه SDN و مشتقات آن ساخته شد.
به طور کلی SDN شبکه را به دو بخش Control plane و data plane یا همان forwarding تقسیم میکند. اینگونه شبکه به قسمت هایی که بهم وابستگی ندارد شکسته میشود. بخش کنترلر وظیفه مدریت بخش data و اعمال سیاست های مدیران شبکه را بر عهده دارد. این مرکز امکان مدیریت متمرکز شبکه و دستگاه های آن را برای مدیران فراهم میکند. البته مشکل آن بخش سرعت بسیار پایین آن نسبت به صفحه data است. برای همین امروزه بیشتر از مدل توزیع شده صفحه کنترلر استفاده میکنند.
بخش data مسئول forward کردن بسته های شبکه به دستگاه یا hop بعدی است.
به طور مثال فرض کنید یک بسته وارد شبکه مبتنی بر SDN شده. حال دستگاه های مسیریاب در آن شبکه مسئول مسیریابی آن بسته بر اساس قوانین و سیاست های تعریف شده توسط مدیران در صفحه کنترلر هستند. این بسته بعد از مسیریابی و اعمال فیلترهای بسته به hop بعدی ارسال میشود. سپس دستگاه مسیریاب اطلاعات به دست آمده از جریانی که آن بسته به آن تعلق دارد را به صفحه کنترلی ارسال میکند تا مدیران بتوانند در تصمیم گیری های آینده کارکرد شبکه را بهبود دهند.
اما در این زمینه دو تا مفهوم بسیار کاربرد دارد: North bound و south bound. در پروتکل openflow دو تا عبارت آمده است که هر کدام بیانگر یک ارتباط خاص و مشخص در شبکه هستند.
ارتباطاتی که با north bound انجام میشود بین برنامه ها با کنترلر شبکه است و ارتباطات مبتنی بر south boudn بین کنترلر و دستگاه های شبکه است.
خب تا اینجا یکسری از مفاهیم بیان شد حالا بزارید یک تصویر منسجم نسبت به قبل بسازیم.
فرض کنید یک شبکه دارید که یک سرور برنامه کنترلر را اجرا میکند و سرور های برنامه های کاربردی هم یک طرف هستند و همینطور ارتباطات شبکه توسط مسیریاب ها و سوئیچ ها انجام میشود. حالا میخواهیم سیاست های شبکه را بر روی دستگاه ها اعمال کنیم. اینکار توسط openflow بین کنترلر و دستگاه ها صورت میگیرد. یعنی این پروتکل یک API بین صفحه کنترل و داده است.

امروزه به SDN خیلی توجه شده اما این به معنی بی نقص بودن نیست. SDN هنوز دارای مشکلات متعددی است. یکی از مسائلی که هنوز مورد بحث است بحث سازگاریهای امنیتی بین سوئیچ های متصل به کنترلر در شبکه SDN است. این مشکل به دلیل تاخیر پردازش قوانین و نصب آنها در هر دستگاه به وجود می آید. به عنوان مثال مهاجم میتواند آنقدر دستگاه را سرگرم کند تا تاخیر پردازش و نصب قوانین کند تر از دستگاه های دیگر شود. از آنجایی که این مسئله یک مسئله مربوط به امنیت شبکه است مقالات روی این موضوع توسط پژوهشگران حوزه امنیت کامپیوتر نوشته میشود.
اما از مشکلات دیگر در حوزه SDN مسئله مقیاس پذیری و قابلیت اطمینان است. همونطور که قبلا هم گفتم یکی از مشکلات SDN کند بودن یا آهسته بودن صفحه کنترل است. از طرف دیگر تعداد جریان ها و ارتباطات در شبکه در هر ثانیه میتواند به بیش از 1000 تا جریان برسد. این امر موجب میشود که تصمیمات مدیریتی در شبکه و اعمال قوانین جدید با مشکل مواجه شود. راه حل آن مقیاس پذیری صفحه کنترل است. یعنی بتوان چندین صفحه کنترل داشت و این ها با همکاری هم صفحه داده را کنترل کنند. اما این مورد هم چالش دارد. اولین چالش آن مسئله sync بودن آن هاست. یعنی در همه کنترلر ها حالات با وضعیت شبکه باید یکسان باشد. در صورت همگام نبودن وضعیت در یک کنترلر آنگاه تصمیمات و قوانین در شبکه دچار ناسگاری میشود.