1. Efficient Round-Trip Time Monitoring in OpenFlow Networks
Alon Atary
Anat Bremler-Barr
Interdisciplinary Center Herzliya
להגיד:
במצגת הזו אציג תשתית לניטור RTT ברשתות OpenFlow
העבודה נעשתה בהנחייתה של פרופ' ענת ברמלר בר ותוצג בINFOCOM 2016.
Supported by the European Research Council, and Neptune Consortium.

2. Motivation: Granular RTT Monitoring
RTT – Round Trip Time
Time to send a packet and receive a response
Applications: Bottlenecks and anomalies detection, traffic engineering
Existing Tools, such as Ping and Traceroute,
are limited in traditional networks
Only between L3 entities
Cannot measure any selected route
Routing changes
𝑠 1
𝑠 2
מטרת השקופית:
להסביר מהר, מה המוטיבציה שלנו, למה אנחנו רוצים לעשות זאת (למה מדידות של RTT יכולות לשמש), למה אנחנו חושבים שיש בעיה עם הכלים הקיימים.
להגיד:
לאחר הכותרת
המוטיבציה שלנו היא למדוד RTT ברזולוציה גבוהה כדי שנוכל להתמקד בסגמנטים ספציפיים של הרשת ולקבל תוצאות שיתנו לנו יותר משמעות.
בולט ראשון- מה זה RTT?
RTT הוא הזמן שלוקח לפקטה לצאת מנקודה A ברשת, להגיע לנקודה B ולחזור.
חשוב לציין כי מדידה יחידה לא תספיק וביצוע מדידות חוזרות יכול להעיד על מגמות ושינויים ברשת.
(הנפשה – פעמיים פקטה שהולכת בין s2 לs6 כדי להסביר שזה זמן הלוך חזור וכי צריך כמה מדידות ולכן לרוב אנחנו מדברים על ניטור ולא על מדידות).
בולט שני– למה זה יכול לשמש?
השימושים שיכולים להיות למדידות של RTT עם רזולוציה יותר גבוהה מאוד מגוונים, אפשר יהיה לזהות בקלות רכיבים שמהווים צוואר בקבוק או את המקור של אנומליות ברשת. בנוסף המון אפליקציות של OF בונות על חידושים וניתובים חדשים מבלי לדעת באמת מה הRTT של רכיבים שונים ברשת. המידע הזה יכול להוות input נהדר לתכנון נכון יותר של תעבורת הרשת. (זה יישום של ידע בסטטיסטיקה , תורת התורים, מודלים ומדידות בשביל לתכנן רשתות).
יותר מפורט
ישנה דרישה לכלים מתקדמים יותר לניתוח ביצועים וניהול רשת. מדידות של RTT בין נקודות שונות ברשת יכולות לסייע בהבנת ביצועי הרשת. בנוסף, מדידה של RTT יכולה לעזור למנהלי הרשת להבין את התגובתיות של הרשת (יכול להיות קריטי לשימוש באפליקציות כמו voip)
כאשר נמדוד RTT של לינקים נוכל לזהות רכיבי רשת שמהווים צוואר בקבוק ברשת, לבודד נקודות עמוסות ולזהות ביעילות אנומליות ומה המקור שלהן.
מדידה של RTT של מסלול מעגלי כלשהו ברשת (RTP) יכולה לסייע בהערכה של פרוטוקולי ניתוב שונים. בנוסף המידע הזה יכול להיות input לבנייה של פרוטוקולי ניתוב אופטימליים בזמן אמת.
בולט שלישי– הכלים
הכלים הנפוצים ביותר למדידת RTT הם ping וTraceroute, לכלים אלו יש 3 מגבלות מאוד משמעותיות כשבאים למדוד RTT ברזולוציה של לינק בודד.
הכלים האלו עובדים עם ברכיבי רשת שיש להם כתובות IP ומתאימים יותר למדידות של RTT בין רשתות שונות או ברשתות גדולות. הscope של הפתרון שלנו אנחנו מגבילים את עצמנו למדידות בתוך הרשת (intra-network) ולא בין רשתות (inter-network). בנוסף הכלים הללו לא נותנים פתרון טוב לבעיה של גראנולריות כאשר רוצים להתמקד בסגמנט רשת קטן יותר.
לשם כך מאמר שיצא לאחרונה ממעבדות המחקר של Microsoft ועוסק בכלי שנקרא pingMesh שמטרתו לפתור את בעיית הגראנולריות. העניין הוא שהמאמר עוסק ברשתות בסקאלות גדולות יותר כמו data centers ואז מספק גראנולריות ברמה של תתי רשתות ולא מגיע לרזולוציה של לינק בודק או מספר לינקים ספציפי.
2) אין שליטה בניתוב ברשת, ולכן לא תמיד ניתן למדוד את סגמנט הרשת אותו אנחנו רוצים למדוד.
(הנפשה של מסלול באדום שלא בטוח שנצליח למדוד)
בנוסף, יש לינקים שבהנתן ניתוב מסויים בכלל לא בטוח שניתן לכסות אותם.
(הנפשה של לינק בצהוב שלא בדוק שעוברים עליו ואפשר למדוד אותו).
יכול להיות שתעלה פה השאלה שאומרת שאם הוא לא בשימוש גם ככה למה שנרצה למדוד אותו, והתשובה היא שיכול להיות שהוא לינק מאוד קצר ולא עמוס שיכול לעזור לניתוב יעיל יותר וחלוקת העומס בדרך אל s2.
3) בגלל האופי של פרוטוקולי התקשורת, לעיתים קרובות הניתוב הוא דינאמי ולכן אין קונסיסטנטיות במה שאנחנו מודדים, משמע שננסה לחפש אנומליות יהיה קשה יותר להבין האם הן נגרמו בגלל שינוי בפרוטוקול הניתוב או בגלל עומס על סגמנט ספציפי ברשת – מוביל לחוסר דיוקים.
לסיכום, המדידות שנוצרות בעזרת הכלים הקיימים אינן יציבות ,פחות מדוייקות ולא מתאימות לעבודה בתוך רשתות או ברזולוציה גבוהה.
𝑠 3
𝑠 4
𝑠 5
𝑠 6
𝑠 7

3. Goal: RTT Monitoring in OpenFlow
Scalable, generic and efficient RTT monitoring of:
All links in the network (L2)
𝑠𝑖𝑛𝑔𝑙𝑒 𝑙𝑖𝑛𝑘: 𝑅𝑇𝑇 𝑠 2 ↔ 𝑠 1
Any selected round trip path (RTP)
𝑆𝑦𝑚𝑚𝑒𝑡𝑟𝑖𝑐 𝑅𝑇𝑃:𝑅𝑇𝑇 𝑠 2 → 𝑠 4 → 𝑠 6 → 𝑠 4 → 𝑠 2
𝐴𝑠𝑦𝑚𝑚𝑒𝑡𝑟𝑖𝑐 𝑅𝑇𝑃:𝑅𝑇𝑇 𝑠 2 → 𝑠 3 → 𝑠 4 → 𝑠 2
OpenFlow
No support for RTT time measurements
Full control over network routing
Duplication, Tagging
OpenFlow Controller 1
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5 2 3
מטרת השקופית:
להסביר את המטרה שלנו ולהסביר למה אנחנו רוצים להשתמש בopenflow.
להגיד:
לאחר הכותרת
המטרה שלנו היא להצליח לנטר RTT ברשתות OpenFlow.
בולט ראשון – איזה פתרון צריך להיות
אנחנו רוצים ליצור פתרון שיהיה קל להרחבה, כללי ויתאים לכל רשת, ויעיל כך שלא יצטרך הרבה משאבים בשביל ניטור RTT משני סוגים:
כל הלינקים ברשת והמשמעות היא בין כל שני switches ברשת.
(הנפשה) לדוגמא זה המסלול שפקטה צריכה לעבור בכדי למדוד את הRTT של הלינק בין s_2 לבין s_1.
כל המסלולים המעגליים ברשת, שמתחלים ומסתיימים באותו switch.
(הנפשה) לדוגמא זה המסלול שפקטה צריכה לעבור בכדי למדוד את הRTP שמתחיל בs_2.
לדוגמא מסלולים סימטריים, או מסלולים אסימטריים ברשת.
בולט שני- openflow
אנחנו כאמור רוצים לתת פתרון בעולם של OpenFlow, openflow פתח עולם חדש של הזדמנויות והמון אפליקציות משתמשות בו כדי לתת פתרונות חדשניים, עם זאת אין תמיכה למדידות יעילות של RTT ברשתות וזה מה שאנחנו בהם לספק.
(הנפשה של מוח ששולט ברשת).
היתרון המרכזי שלו הוא העובדה שהוא מאפשר שליטה בניתוב ברשת, נותן נקודת מבט כוללת על הרשת ומספק למעשה גמישות ביצירת הפתרון שלנו.
מעבר לזה, הוא:
תיוג של פקטות שיאפשר לזהות אותם לאורך הניתוב ברשת ולאחר מכן בשלב הניתוח.
מאפשר שכפול של פקטות מה שאפשר לנו הפצה של פקטות בצורה יעילה.
שני דברים אלו מאפשרים לנו יעילות לפתרון.
חשוב לציין כי הפתרון שלנו מתאפשר רק ברשתות שעובדות עם Openflow החל מגרסא 1.3, והפתרון הזה לא היה פיזאבילי ברשתות רגילות. 4 1 2 3 2

4. Our solution – GRAMI GRAnular RTT Monitoring Infrastructure
GRAMI works in two phases:
Offline: Controller application finds a location set for k measurement points (MPs) and builds an overlay network
Online: Active probing from the MPs in measurement rounds
The RTT of a single link\RTP is calculated in the MPs by subtracting the RTT of different paths
Controller application
= −
𝑟𝑡𝑡 𝑠 1 ↔ 𝑠 2
𝑟𝑡 𝑡 𝑚 1 ↔ 𝑠 1 ↔ 𝑠 2
𝑟𝑡 𝑡 𝑚 1 ↔ 𝑠 1
𝑚 1
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
מטרת השקופית:
בשתי מילים על GRAMI איך הפתרון עובד.
להגיד:
לאחר הכותרת
Openflow נתן לנו את האפשרות לבנות את הפתרון שלנו GRAMI שזה GRAnular RTT Monitoring Infrastructure
הפתרון עובד בשני שלבים מרכזיים.
בולט ראשון – שלב offline
השלב הראשון הוא שלב הoffline שבו אפליקצייה מותקנות על הקונטרולר, מוצאת k נקודות מדידה בהתאם למספר הנקודות שנותנים לה ובונה רשת מכסה בהתאם לנקודות האלה.
(הנפשה מוסיפה את האפליקציה)
האפליקציה מותקנת מעל הקונטרולר
(הנפשה שולחת הודעות ומוצאת נקודות מדידה)
הcontroller מוצא את נקודות המדידה.
נקודות מדידה אלו מחשבים שמחוברים לרשת עליהן הותקנה אפליקציה שהיא חלק מהתשתית, האפליקציה שולחת הודעות בדיקה שמתפשטות וחוזרות אליה ואז מודדת את הRTT של רכיבים שונים ברשת
יש תמיכה בכל מספר של נקודות מדידה (k נקודות מדידה). במקרה שלנו המיקום של 2 נקודות המדידה נבחר להיות.. (המערכת תדע לבחור מיקום טוב אם הוא לא ניתן מראש).
(הנפשה מוסיפה רשת מכסה)
האפליקציה מוסיפה רשת מכסה שהיא רשת כיוונית שתתווה את הכיוון של הפקטות שימדדו את הRTT.
בולט שני – שלב online
השלב השני הוא של הonline שבו נשלחות פקטות בצורה אקטיבית מנקודות מדידה מוגדרות הרעיון הוא לשלוח פקטות בדיקה של interval ידוע מראש שיעבור על גבי מסלולים קבועים ויחזרו לאותה נקודה ממנה הן יצאו. הפקטות הללו יעברו ניתוח בנקודת המדידה והתוצאות ישלחו לכל מי שצריך אותן.
(הנפשה שליחת הודעות לרשת)
יש מספר שליחות כי שולחים מספר פעמים בסיבובי מדידה.
(הנפשה שמוסיפה את הכיתוב)
מכיוון שנקודות המדידה לא צמודות לכל לינק ולכל מקום שאנחנו נרצה למדוד, אנחנו מעריכים את הRTT להיות ההפרש בין כמה RTT שונים
(הנפשה מוסיפה את הלינק שאנחנו רוצים למדוד)
נניח שאנחנו רוצים למדוד את הRTTT הזה?
לדדוגמא עבור הלינק שלנו נמדוד את ההפרש בRTT של שני מסלולים:
(שתי הנפשות שונות)
ואז נחסר ביניהם ונשערך את הRTT להיות ההפרש
יש שיטות יותר מתקדמות מחיסור בשביל לחשב בצורה מדוייקת יותר שני משתנים עם variance אבל זה לא משהו שהעבודה שלנו התמקדה בו.
הרחבה
ההבנה שלא יכולה להיות לנו גישה לכל השיטות ושאנחנו לא רוצים לעשות שינויים פיזיים בswitches כדי לגרום להם לשלוח אקטיבית פקטות מאלצת אותנו לעשות מניפולציה מסויימת על מדידות בכדי להעריך את הRTT. יש שיטות סטטיסטיות יותר מתקדמות בשביל לחשב במדוייק חיסור של שני משתנים עם variance אבל זה מחוץ לscope של המחקר שלנו. יתר על כן, אנחנו מניחים שאם יש middleboxes או switches כחלק מהניתוב שלא ניתן היה לשלוט בהן אז הניתוב שלהן יהיה קונסיסטנטי עבור הפקטות שלנו ואנחנו נתייחס אל רכיבים אלו כחלק מהלינק הנמדד.
𝑚 2

5. Agenda Solution overview Solution drilldown Related work
Considerations
Workflow
Solution drilldown
Related work
Experimental results
אז מה יהיה לנו היום?
נתחיל ממבט על על הפתרון, נבין מה הייתה המטרה שלנו ביצירת התשתית ומה היו השיקולים שליוו אותנו, ואז נראה את work flow של הפתרון ממבט על בזריזות.
לאחר מכן נכנס קצת יותר לעומק לכל אחד מהשלבים המרכזיים של הפתרון.
נדון בקצרה בקונספטים של עבודות דומות שנעשו ולבסוף נציג את התוצאות שלנו.
נסו לזכור את האייקונים הללו, האייקונים הללו ילוו אותנו לאורך המצגת בכדי לעזור להבין באיזה שלב אנחנו.

6. GRAMI considerations Compatibility with every OpenFlow network
No assumptions on topology or size
No changes to switch software or hardware
No time synchronization
Resource efficient
Minimal number of probe packets and flow entries
Up to 4+2𝑟 flow entries for 𝑟 RTPs and 𝑛 links
Minimal controller involvement
Accurate and consistent
Flexible
Any number of MPs located on demand
Dynamic updates
מטרת השקופית:
לענות על השאלה מה היו השיקולים שלנו. להסביר בכל אחד מהשיקולים בגדול איך עשינו את זה.
להגיד:
לאחר הכותרת
בתכנון הפתרון שלנו היו לנו כמה שיקולים.
בולט ראשון –תאימות לכל רשת openflow.
התשתית צריכה לעבוד עם כל רשת open flow. לכן ולכן אנחנו לא עושים הנחות על טופלוגיה או גודל הרשת. אנחנו לא עשינו שם שינוי בswitches ברמת התוכנה או ברמת החומרה, או בפרוטוקול של Openflow . לכן פתרונות כמו לשלוח את ההודעות מהswitches עצמם הוא לא פתרון אפשרי מבחינתנו כי הטמעה של שינוי כזה שידרוש שינוי חומרתי או לפחות תוכניתי הוא כנראה לא סקלאבילי. אנחנו מניחים כי אין סנכרון זמנים בין רכיבים שונים ברשת. מכיוון שסנכרון זמנים זו משימה לא פשוטה ברשתות, במיוחד אם רוצים סנכרון ברזולוציה גבוהה, ומכיוון שהעומס על הרשת גדל כאשר מנסים לסנכרן זמנים, במידה והייתה היינו יכולים למדוד גם one way delay ולא רק RTT.
כשמדבר על סנכרון זמנים מדבר על סנכרון בין switches ובין רכיבי רשץ
בולט שני – יעילות של משאבים
מכיוון שאחת המטרות שלנו היא יעילות, אנחנו רוצים להשתמש במשאבי הרשת בצורה חכמה. אנחנו משתמשים במספר קטן של פקטות מדידה כי המטרה היא לא להעמיס על הרשת מכיוון שאם נעמיס עליה נפגע במדידות ובמספר קטן של חוקים על הswitches מספר הflow entries בopenflow מוגבל ומעבר לזה ככל שהוא גדל יש דגרדציה ביעילות של הswitch.
מעורבות מינימלית מצד הcontroller, הcontroller הוא לא חלק מהמדידות אלא רק חלק מהתהליך הכנה למדידות. מכיוון שהcontroller הוא לרוב הנקודה היא עמוסה ברשת ומכיוון שמאמרים שונים הראו שמדידה של הRTT דרכו יכולה לגרום לאי דיוק נרצה כי פקטות הבדיקה לא יעברו דרך הcontroller ושהחלק שלו בתהליך יהיה קטן כמה שיותר. לכן בפתרון המוצע, הcontroller יהיה אחראי רק על התקנת החוקים בשלב האתחול, לאחר מכן פקטות הבדיקות לא אמורות לעלות אליו ובכלל ולא להעמיס עליו מכיוון שהניתוב שלהן כבר קבוע. במידת הצורך יהיה מעורב בעדכונים אוטומטיים.
בשביל לדאוג לניתוב הנכון אנחנו צריכים 4 חוקים על כל switch ומקסימום 2 חוקים נוספים על כל אחד מהswitches ברשת.
בולט שלישי – דיוק
אנחנו רוצים שהפתרון שלנו יתן תוצאות מדוייקות ועקביות, לכן בבחירת המיקום של הMPs ובבניית הרשת המכסה, אנחנו נדרוש כי העומק של הלינקים יהיה מינימלי וכי הלינקים יתחלקו כמה שאפשר שוה בשווה בין MPs.
בולט רביעי - גמישות
רצינו לאפשר למשתמש לבחור מכמה נקודות הוא רוצה למדוד את הרשת ואיפה הוא רוצה למקם אותם. פה זה מאפשר למשתמש לתעדף בין דיוק (שהולך וגדל ככל שמודדים מיותר נקודות) לבין תחזוקה שנובעת מהצורך להפעיל מספר נקודות מדידה במקום נקודה אחת.
בולט חמישי - עדכונים דינאמיים.
רשתות בסופו של דבר זה דבר דינאמי, ברמת שונות, חלקן נוטות להשתנות בקצב מהיר ואילו אחרות משתנות בקצב איטי יותר, אבל ברגע שנעשה שינוי, המערכת צריכה לדעת לזהות אותו ולעדכן את המסלולים שהיא מודדת בהתאם. אחרת, כל שינוי ידרוש התקנה ידנית וזה מטרד רציני למפעיל הרשת. לכן דאגנו כי GRAMI יידע לזהות את השינויים ולתקן את הflow entries בכדי להמשיך לעבוד בצורה אוטומטית ללא התערבות חיצונית.

7. Workflow – offline and online phases
How many MPs?
Which RTPs?
Offline Calculations – Controller Application
Establish the overlay network
Derive and install flow entries
Controller app
Compute MPs location set
𝑚 1
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
Online RTT Monitoring – MPs
מטרת השקופית:
לענות על השאלה איך המערכת עושה את זה לפי שלבים אבל עדיין להציג overview ולא להכנס לכל שלב בפתרון..
מה להגיד:
הwork flow מתחלק לשני חלקים מרכזיים – offline וonline.
חישובי offline- תחת האחריות של הcontroller application
בחלק הoffline, אפליקציה שתתוקן על הcontroller תתכנן מראש את המסלול של פקטות הבדיקה עוד לפני שמתחילות המדידות, זאת בכדי שבזמן המדידה הcontroller לא יהיה מעורב.
אפליקציית הcontroller מקבלת מהמשתמש את המידע הבא, כמה MPs להשתמש (אפשרי גם לבחור איפה לשים אותם או את חלקם) ואילו RTPs צריך למדוד. את המידע הזה אפשר לקבל באיזה פורמט שנרצה.
(ואם צריך למצוא את הטופולוגיה משתמשים באפליקציה למציאת טופולוגיה)
שלב ראשון – האפליקציה תחשב את המיקום של נקודות המדידה במידה והן לא נתונות, למיקום של נקודות המדידה יש השפעה מכרעת על איכות הרשת המכסה שנבנה (הכוונה היא לעומק הממוצע ברשת ולעומק המקסימלי).
שלב שני - נחשב את הרשת המכסה. הרשת היא רשת ללא מעגלים שבה יש מסלול יחיד, סימטרי וקצר ביותר לכל אחד מהswitches והלינקים ברשת.
שלב שלישי – התשתית תגזור מהרשת לכל אחד מהswitches את הflow entries הנדרשים על מנת למדוד גם את הלינקים וגם את הRTPs.
חישובי online - תחת האחריות של הMPs
לאחר שהתשתית נבנתה והחוקים הותקנו יתחיל חלק הonline, בחלק זה, נקודות המדידה ישלחו הודעות בדיקה כל זמן קבוע, ההודעות יעבור על הרשת ויחזרו לנקודת המוצא שלהן ואז נקודות המדידה ינתחו את המידע לשם חישוב הRTT. להדגיש שפה האחריות היא של נקודות המדידה.
שלב רביעי - שליחת הפקטות ברשת – כל זמן קבוע, נקודות המדידה ישלחו פקטה יחידה, הפקטות ישוכפלו ויופצו ברשת ויכסו כל אחד מהלינקים בדיוק פעם אחת וכל מסלול שנדרש בדיוק פעם אחת. לאחר מכן יחזרו לנקודות המדידה. חשוב לציין כי בזמן שהפקטות עוברות על גבי הרשת הן לא רק משוכפלות אלא גם נוסף להן תיוג שמעיד על המסלול שהן עברו או צריכות לעבור. הצבעים השונים מתארים פקטות בשלבים שונים של ההפצה וזה יוסבר יותר לעומק בהמשך.
חישוב הRTT – המידע שחוזר לנקודות המדידה עובר עיבוד ופעם בזמן מוגדר נשלח לcontroller או לכל גורם שידרוש את זה סיכום של התוצאות.
(הנפשה שמעלימה את המחשבונים ומוסיפה את הswitch החדש).
להרחבה
במידה ויהיו שינויים ברשת, התשתית תדע לזהות זאת על ולבנות את התשתית מחדש (אנחנו משתמשים באפליקציה לזיהוי טופולוגיה שכתבנו).
𝑚 2
Probe packets distribution
RTT calculations

8. Step 1 offline phase: Compute the MPs location set
Optimal MPs location set:
Minimize the maximal depth
Lower depth = Higher accuracy
Balances the number of links measured by each MP
Balance the number of return probe packets
𝑚 1
𝑠 1
𝑠 2
להגיד:
אחרי הכותרת:
כעת נתחיל לפרט קצת יותר לעומק על כל אחד משלבי הפתרון.
השלב הראשון בחלק הoffline הוא מציאת סט המיקומים האופטימלי של הMPs.
בולט ראשון- מה נתון ומה רוצים לחשב
אנחנו יודעים בכמה MPs אנחנו רוצים להשתמש. אנחנו רוצים לחשב את סט המקומות האופטימלי שבו אנחנו רוצים למקם את הMPs.
(הנפשה של הכנסת המיקום האופטימלי)
(הנפשה שמכניסה את הדרישה הראשונה)
הדרישה הראשונה היא שהמרחק של הלינק המקסימלי מנקודת המדידה הכי קרובה אליו יהיה מינימלי.
(הנפשה צובעת את הלינקים לפי עומק)
מבדיקות שעשינו, מה שהכי גרם לרעש במדידות היה העומק של הלינק, משמע כמה לינקים היו בין הלינק הנמדד לבין הMP. מכיוון שכל לינק וswitch בדרך מוסיף רעש אנחנו נרצה תחילה, כי המרחק המקסימלי ברשת (המרחק של הלינק הכי רחוק מMP) יהיה מינימלי. במידה ויש שיוויון נרצה שמספר מינימלי של קשתות יהיו בעומק הזה.
(הנפשה שמחזירה את הצבע ומראה את הדרישה השנייה)
הדרישה השנייה, בהנתן שהדרישה הראשונה מתקיימת היא שמספר הלינקים תחת האחריות של כל אחד מהMPs יהיה מאוזן כדי לא ליצור עומסים על MP אחד ופחות עומסים על MP אחר. שוב, רק אם זה לא פוגע בעומס.
(הנפשה שמחלקת את הלינקים לפי צבעים MP)
(הנפשה שמכניסה את הכיתוב של מספר הפקטות החוזרות.
למעשה, מכיוון שחוזרת פקטה יחידה עבור כל לינק, נרצה שמספר הפקטות החוזרות מכל הלינקים לMP יהיה מאוזן.
𝑚 2
𝑠 3
𝑠 4
𝑠 5
𝑠 6
𝑠 7

9. Step 1 offline phase: Compute the MPs location set
NP-hard problem – select the better location set of two polynomial approaches:
Farthest-first traversal greedy algorithm
Choose first switch randomly
Add farthest switch
Result – 5 links with depth 3
𝐷𝑒𝑝𝑡ℎ = 2𝑜𝑝𝑡+1
Local-search heuristic
Choose optimal switch
Add optimal switch
Result – 2 links with depth 3
𝑚 1
𝑚 1
𝑠 1
𝑠 2
להגיד:
בולט ראשון - בעיה קשה
הבעיה של מציאת סט מקומות אופטימלי מאוד דומה לבעיה ידועה שנקראת metric k-center problem, אפשר לעשות רדוקציה על ידי מיקום של נקודה באמצע כל צלע ולגלות שלמצוא שהבעיה הזו היא NP-hard. ( עושים רדוקציה מבעיה שהיא בNP ולכן היא קשה לפחות כמוה).
מכיוון שרצינו שהפתרון יהיה מהיר וסקלאבילי, החלטנו לבחור את האופטימלי בין שני פתרונות שהם מהירים
. ( הנפשה) הכנסה שם של אלגוריתם ראשון
(הנפשה בחר את המיקום הראשון רנדומית עם הכנסת MP)
(הנפשה בחר את השני הכי רחוק)
(הנפשה הכנס תוצאה עם צבעים, סך הכל 5 בעומק 3)
הוכיחו כי הדבר הזה נותן קירוב 2, ועם הרדוקציה שלי אני מקבל קירוב 2opt+1.
(הנפשה הסר את הפתרון של הדרך הראשונה והצג שורה ראשונה)
( הנפשה בחר את הראשון האופטימלי)
(הנפשה בחר את השני האופטימלי בהנחה שהראשונה כבר שם).
(הנפשה עם הכנסת תוצאות וצבעי, סך הכל 2 עם עומק 2.
הסיבוכיות של הראשון:
O(kn) כי זה k סיבובים כפול BFS שזה O(|E|+|V|)=O(|E|)=O(n)
הסיבוכיות של השני:
O(kn) כי בודקים n מקומות למשך k סיבובים וכל פעם עושים BFS כדי למצוא את האופטימלי ולכן בסך הכל O(kn*n)=O(kn^2)
הפתרון הוא פתרון incrementaly.
(הנפשה שמדגישה שנבחר את הפתרון השני).
𝑚 2
𝑠 3
𝑠 4
𝑚 2
𝑠 5
𝑠 6
𝑠 7

10. Step 2 offline phase: Establish the overlay network
Sets a singular shortest path from every switch and link to its closest MP
Accuracy
Fixed routing
Every link and RTP is measured exactly once
Minimal overhead caused by probe packets
𝑚 1
𝑠 1
𝑠 2
להגיד:
אז יש לנו את המיקום של הMPs, כעת נרצה לבנות את הרשת המכסה
אז מה המטרה של הרשת המכסה?
בולט ראשון – מה אנחנו רוצים להשיג:
לרשת המכסה יש שתי מטרות מרכזיות
הראשונה – לוודא שלכל אחד מהלינקים יש מסלול אחד ויחיד לכל אחד מלינקים והswitches מהMP הקרוב ביותר. מעבר לכך המסלול צריך להיות קצת יותר.
הסיבה שאנחנו רוצים שהוא יהיה הקצר ביותר הוסברה כבר קודם והיא שאנחנו רוצים תוצאות כמה שיותר מדוייקות.
עצם העובדה שיש דרך אחת בלבד להגיע לכל אחד מהלינקים והswitches מבטיחה לנו שהניתוב יהיה קבוע (כך לא יהיו לנו שינויים לא צפויים שנגרמו משינויים בניתוב).
להרחיב
המסלול תמיד יהיה סימטרי כי סימטרי זה הכי קצר שאפשר.
השנייה – כל לינק וכל RTP ימדדו פעם אחת בלבד בכל סיבוב של מדידות.
הסיבה היא שאנחנו רוצים מספר מינימלי של הודעות ולא נרצה שהפקטות מדידה שלנו יעבור יותר מדי סיבובים.
𝑚 2
𝑠 3
𝑠 4
𝑠 5
𝑠 6
𝑠 7

11. Step 2 offline phase: Establish the overlay network
For a single MP:
Set a shallow spanning tree
Solid links
Add the rest of the links
Dashed links
Terms:
Parent link: The single ingress
solid link of every switch.
Singular shortest path to every switch
Egress links: links directed out
Every link is measured exactly once
𝑚 1
𝑠 1
𝑠 2
להגיד:
בולט ראשון – איך בונים את הרשת לMP יחיד:
הבנייה היא דו שלבית:
(הנפשה הכנסה שלב ראשון יחד עם עץ פורש רדוד).
בשלב הראשון ניצור עץ פורש רדוד, שזה עץ שהשורש שלו הוא הMP והוא מורכב מהמסלולים הכי קצרים לעבר כל אחד מהswitches. ניתן לעשות זאת על ידי הרצה של אלגוריתם BFS מהMP.
נשים לב שהלינקים הרציפים יוצרים דרך הכי קצרה ויחידה לכל אחד מהswitches.
להרחיב
יש לנו כל מיני אופטימיזציות אנחנו עושים את הבנייה קצת יותר חכמה ונותנים משקל לכל אחד מהלינקים במידה והוספה שלו תגרום להוספה של עוד לינקים בוודאות, אנחנו למעשה מנסים לאזן את העץ גם ברמה אחת מתחת לMPS.
(הנפשה מכניס את השלב השני וקווים מקווקים).
את שאר הלינקים נוספים בתור לינקים מקווקים, ממש עוד מעט נסביר את ההבדל בין לינקים רציפים למקווקוים ומדוע עשינו את ההפרדה
(הנפשה שמסובבת לינק)
נשים לב שהכיוון של הלינקים המקווקים גם מאוד משנה כי נרצה שיהיה לו את העומק המינימלי, ואם נסובב העומק יהיה 4 ולכן גם בזה התחשבנו.
בולט שני– מושגים חשובים.
(הנפשה מכניסה את המושג של לינק אבא ואת הלינק האדום של switch 6)
שני מושגים שחשוב שיכירו, אחד זה לינק אבא, שהוא הלינק היחיד הרציף שנכנס לתוך כל switch, חשוב להבין שברגע שנכנס מהלינק הורה אז אפשר לדעת שהגענו לswitch מהMP הרלוונטית ואפשר לדעת שזה קרה פעם אחת.
(הנפשה, דרך הכי קצרה עם עוד לינק אדום)
נשים לב שאם נחזור על הswitches דרך הלינק הורה שלו כל פעם, נחזור בדרך היחידה הכי קצרה לMP ממנו יצאנו.
(הנפשה שמכניסה את המושג של לינקים יוצאים בירוק)
מושג שני שתכירו זה לינקים יוצאים, כי רק אליהם במהלך ההפצה נעשה את ההפצה.
(הנפשה שתכניס את העובדה שזה מודד פעם אחת)
עצם העובדה שיש ללינקים כיוון, זה נותן לנו את כיוון ההפצה שלהם וימנע ממצב שבו נדוד לינקים גם משני הצדדים שלהם. .
𝑚 2
𝑠 3
𝑠 4
𝑠 5
𝑠 6
𝑠 7

12. Step 2 offline phase: Establish the overlay network
In case of multiple MPs:
Divide links between k MPS
k sub networks with single MP
Create an overlay network for each sub network
Merge sub networks
Validate single parent link
𝑠 2
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑚 2
𝑠 1
𝑠 3
𝑚 1
𝑠 2
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑚 2
𝑠 1
𝑠 3
𝑚 1
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑚 1
𝑚 2
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑚 1
𝑚 2
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑚 1
𝑚 2
𝑚 1
𝑚 2
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
להגיד:
בולט ראשון – איך בונים את הרשת לכמה MPs:
זה מתחלק ל-4 שלבים:
(הנפשה שמפצלת את הלינקים)
שלב ראשון, חלק את הלינקים בין הk MPs
שימו לב כי יש switches שמופיעים בשתי רשתות ושיש לנו למעשה עכשיו k רשתות עם MP יחיד בכל אחד מהם, למעשה אנחנו יודעים לפתור כבר את הבעיה הזו.
(הנפשה שבונה את הoverlay networks לכל אחת מהרשתות ומציגה את שלב 2)
נבנה את הרשת המכסה לכל אחד מהרשתות שנוצרו
(הנפשה שמחברת ומציגה את שלב 3)
מה שנעשה עכשיו זה לאחד את כל הרשתות, למעשה ניקח את הלינקים מכל אחת מהרשתות שיצרנו ונעתיק את הסוג והכיוון שלו לרשת המקורית.
(הנפשה שמדגישה את העובדה שיש סווטיצ'ים עם 2 לינקים נכנסים באדום)
נשים לב שיש לנו פה בעיה, יש סוויטצ'ים עם כמה parent link,
(הנפשה שמציגה את שלב 4 יחד עם החלפה של רציפים למקווקים).
נדאג שלכל אחד מהswitches יהיה לינק אב יחיד, בהתאם לכמה לינקים זה מוסיף ולצורך שהדרך תהיה הקצרה ביותר.

13. The online phase: Tagging packets is common and efficient in OpenFlow
Vlan, Ethernet, Payload
Probe packet types:
Packet type affects switch behavior
Forward
Return
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑚 1
𝑚 2
Link
להגיד:
אחרי הכותרת –
דילגנו על שלב 3 בחלק הoffline כי בכדי שנוכל להבין אותו באמת, צריך להבין קודם את מה קורה בonline.
בולט ראשון
במהלך המעבר על הרשת הswitches מוסיפים תיוגים לפקטה כדי לספק מידע על איזה מסלול הפקטה עברה ומה היא אמורה לעבור, על בזה נתמקד בהמשך, כרגע אנחנו מתעסקים אך ורק עם המעבר על הרשת).
(הנפשה) אנחנו השתמשנו בעבודה פה בvlan tags בethernet ובpayload נפרד שאנחנו המצאנו.
(הנפשה בולט של סוגי הפקטות)
בולט שני
נסמן פקטות שהולכות עם הכיוון הרשת המכסה בתור פקטות מקווקות ופקטות חוזרות בתור פקטות מלאות.
ככה נדע עם הפקטה מתקדמת עם הכיוון של הלינקים או הפול
בנוסף, פקטות שמודדות RTP נסמן באדום ופקטות שמודדות לינקים נסמן בסגול.
בולט שלישי
סוג הפקטה הוא שמשפיע על ההתנהגות של הswitch.
RTP

14. Step 1 online phase: Overlay network Probe packet distribution
Single MP, first without RTP
Switches algorithm - Traverse the overlay network: 1. 2. 3. 4. 5. 6. 7. 8. 9.
10.
11.
12.
IF forward packet:
IF link packet:
Send return link packet to ingress port
IF from parent (solid):
Duplicate and Distribute to egress links
IF Return packet:
Tag if needed
Send packet to parent port.
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑚 1
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑚 1
𝑚 2
להגיד:
אחרי הכותרת –
בולט ראשון
(הנפשה של מעבר לswitch יחיד)
אנחנו נתמקד בswitch יחיד בשביל הפשטות ועדיין לא נדבר על איך עוברים על הרשת עם RTPs אלא רק איך עוברים על הרשת.
בולט שני – האלגוריתם שמוכתב על ידי הflow entries שיש בswitches.
כל זמן מוגדר הMPs שולחים הודעה - ההודעה הזו ההיא הודעת forward עם לינק.
(הנפשה של הודעה ואז הנפשה של 3 שורות ראשונות באלגוריתם)
אם זו פקטה שנכנסה עם כיוון קדימה וזו פקטה של לינק אז תחזיר עותק של פקטת חזור כדי למדוד את הסגמנט עד אותה הנקודה ותחזיר מאיפה שבאת כדי שיחזור במסלול סימטרי.
אם הלינק הזה היה לינק הורה (רציף) אז תמשיך את ההפצה ותפיץ לכל הלינקים היוצאים.
(הנפשה של מקרה בלי הפצה מעל לינק מקווקו)
אם הלינק היה לינק שהוא לא parent link אז אל תשכפל אלא רק תחזיר עותק.
ככה זה ימנע מצב שבכל פעם שנגיע לS2 נפיץ לs_4, אלא נפיץ לשם רק שנגיע דרך הparent port
(הנפשה של פקטה חזורת עם שורות 10-12)
שימו לב שהשארתי את שורות 6-9 ריקות, הן ישמשו בהמשך בשביל להבין את הלוגיקה של הRTP.
אם הפקטה הייתה פקטה חוזרת
אז תחזיר אותה, בפועל זה מתחלק לשני מקרים, אחד שדורש תיוג והשני לא. תמיד נחזיר דרך הparent port כדי שיחזור במסלול הכי חזר

15. Step 1 online phase: Full overlay network distribution
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
𝑚 1
𝑚 1 ↔ 𝑠 3
𝑠 1 ↔ 𝑠 2
𝑠 3 ↔ 𝑠 1
𝑠 2 ↔ 𝑠 4
𝑠 3 ↔ 𝑠 2
𝑠 4 ↔ 𝑠 6
𝑠 3 ↔ 𝑠 4
𝑠 6 ↔ 𝑠 5
𝑠 3 ↔ 𝑠 6
𝑠 6 ↔ 𝑠 7
להזכיר התהליך איטרטיבי

16. Step 2 online phase: RTT computations for a single link
RTT of a single link
Always subtract the shortest path
ends with a parent link
If the network is stable, the MP can calculate the RTTs without knowing the topology
𝑟𝑡𝑡 𝑠 1 ↔ 𝑠 2 = 𝑟𝑡 𝑡 𝑚 1 ↔ 𝑠 1 ↔ 𝑠 2 − 𝑟𝑡 𝑡 𝑚 1 ↔ 𝑠 1
𝑚 1 1
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5 2
להגיד:
אחרי הכותרת:
אז איך נעשית המדידה של לינק
בולט ראשון
כמו שאמנו בהתחל, כדי לחשב את הRTT בין s_2 לs_1 נשלח פקטה שמגיעה עד s_1 (הנפשה) בשלב זה מצד אחד תחזור פקטה שתמדוד את המסלול עד לs_1 ומצד שני תצא פקטה שתמדוד את אותו מסלול בנוסף ללינק שנרצה למדוד. ההפרש בין הRTT ייתן הערכה לRTT של הלינק
נשים לב שתמיד נחסר את המסלול שנגמר בparent link.
בולט שני
בגלל התיוגים שאנחנו מוסיפים לפקטה ונסביר עליהם עוד שני, הMP לא צריך להכיר את הטופולוגיה של הרשת, אלא אם כן הרשת היא ממש לא יציבה ונדרשים הרבה שינויים ברשת.

17. Tagging the required information
The MPs should know :
Measurement round
Identify the path traversed.
𝐿𝑖𝑛𝑘 ≡𝐹𝑖𝑟𝑠𝑡 𝑠𝑤𝑖𝑡𝑐ℎ 𝐼𝐷+𝐿𝑎𝑠𝑡 𝑠𝑤𝑖𝑡𝑐ℎ 𝐼𝐷
Identify if return from parent.
Return from shortest part
להגיד:
אחרי הכותרת:
אז אמרנו שהMP לא צריך לדעת את הטופולוגיה בשביל לזהות את המסלול שעברה הפקטה, איך הוא עושה את זה?
בולט ראשון מה הMPs צריכים לדעת:
בשביל ליצור את המדידות הMPs צריכים לדעת 3 דברים:
א) הוא שולח עם הרבה סיבובי מדידה שונים, ולכן הוא מוסיף את המספר סיבוב כדי לשיייך אחר כך את הפקטות החוזרות, הוא מוסיף את זה בpayload והswitches לא מתעסקים עם המידע הזה.
ב) לזהות את המסלול שנמדד להסביר איך יכול להיות מזוהה (הנפשה שמוסיפה את הIDs)
ג) לזהות אם המסלול הקצר ביותר כדי שאותו יוכלו לחסר (להוסיף את הparent flag) שמזהה את המסלול הקצר ביותר לכל אחד מהswitches כדי שנדע אותו לחסר.
Payload
Parent Flag
ID1
ID2
Round Number

18. Step 1 online phase: RTP Probe packet distribution
Let 𝑆 𝑝 to be the first switch in RTP 𝑃
Switches algorithm - Traverse the overlay network and RTP: 1. 2. 3. 4. 5. 6. 7. 8. 9.
10.
11.
12.
IF forward packet:
IF link packet:
Send return link packet to ingress port
IF from parent (solid):
Duplicate and Distribute to egress links
Send forward RTP packet to RTPs
IF RTP packet:
IF not 𝑆 𝑝 : send over RTP 𝑃
IF 𝑆 𝑝 :send return RTP packet to parent
IF Return packet:
Tag if needed
Send packet to parent port.
𝑚 1
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5 3
להגיד:
בשקופית זו נתמקד באיך המערכת מעבירה את ההודעות על גבי RTP (נחזור לתחילת הonline phase ונשלים את המידע הרלוונטי באלגוריתם.
בולט ראשון
נגדיר את sp להיות הswitch הראשון במסלול RTP מסויים אותו אנחנו רוצים למדוד.
בולט שני
כעת נשלים את השורות החסרות באלגוריתם, כדי להבין איך מתמודדים עם RTP
אם הפקטה הגיעה מלינק רציף עם לינק קדימה, תשלח אותה לכל הRTPs כאשר המוטיבציה היא שוב למדוד את כל הRTPs רק פעם אחת.
אם הגיעה פקטת RTP אז צריך לבדוק, אם זה לא sp אז צריך להמשיך לשלוח אותה על המסלול שאנחנו רוצים למדוד, אחרת להפוף אותה לפקטת חזרה עד שתחזור רגיל למקום ממנו יצאה 1 2

19. Step 2 online phase: RTT computations for a single link
RTT of an RTP
𝑟𝑡𝑡 𝑠 2 → 𝑠 2 = 𝑟𝑡 𝑡 𝑚 1 → 𝑠 2 → 𝑠 2 ↔ 𝑚 1 − 𝑟𝑡 𝑡 𝑚 1 ↔ 𝑠 2
𝑚 1
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
להגיד:
אחרי הכותרת:
אז איך נעשית המדידה של RTP
בולט ראשון
כדי לחשב את הRTT של RTP מסויים, הפקטה מגיעה לswitch הראשון במסלול, מצד אחד תחזר פקטה שתמדוד את הדרך עד הswitch הראשון ומצד שני פקטה שתעבור קודם על הRTP ואז תחזור באותו מסלול, ההפרש בין הזמנים יייצג את הזמן של הRTP

20. Tagging the required information
The MPs should know :
Measurement round.
Identify the path traversed.
𝐿𝑖𝑛𝑘 ≡𝐹𝑖𝑟𝑠𝑡 𝑠𝑤𝑖𝑡𝑐ℎ 𝐼𝐷+𝐿𝑎𝑠𝑡 𝑠𝑤𝑖𝑡𝑐ℎ 𝐼𝐷
𝑅𝑇𝑃≡𝑅𝑇𝑃 𝐼𝐷+𝐹𝑖𝑟𝑠𝑡 𝑠𝑤𝑖𝑡𝑐ℎ 𝐼𝐷
Identify if return from parent
Return from shortest part
RTP or Link
להגיד:
אחרי הכותרת:
למעשה הMPs צריכים לדעת פה קצת דבורים נוספים
א) צריכים לזהות את הRTP שהולכים לעבור. וזה אפשר לזהות לפי הswitch הראשון ולתת ID לRTP.
ב) צריכים לדעת האם הפקטה עברה לינק או RTP ולכן מוסיפים RTP flag
VLAN
Header 1
VLAN
Header 2
Payload
Parent Flag
RTP Flag
ID1
ID2
Round Number

21. Tagging the required information
The switches should know:
Packet’s direction
Whether the packet should be tagged
Which RTP to traverse
להגיד:
אחרי הכותרת:
בולט ראשון מה הswitches צריכים לדעת:
א) את הכיוון של הלינק, אבל בגלל שאין דבר כזה לינק עבור הswitch ובטח שאי אפשר לדעת את הכיוון שלו, אפשר לדעת את הכיוון של הפקטה שעליה הוא עובר (הנפשה של direction flag)
ב) לזהות האם צריך עוד לתייג את הפקטה או שהיא כבר מתוייגת (הנפשה של set ID Flag)
ג) לזהות את הRTP שהפקטה צריכה לעבור עליו שיתוייג בID2 (הנפשה של הדגשה של ID2).
VLAN
Header 2
VLAN
Header 2
Ethertype
Payload 21
Direction Flag
Set ID Flag
Parent Flag
RTP Flag
ID1
ID2
Round Number

22. Step 3 offline phase: Derive and install flow entries
Directly derived from online behaviors
Traverse the overlay network (1-4), traverse RTP 𝑃 (5-6)
Travrse and network and measure the links
להגיד:
לא נכנס הכי לעומק עם החוקים, אבל הטבלה נמצאת פה.
בולט ראשון – תרגום
כל רשומה מתורגמת ישירות מההתנהגות המקבילה בonline phase, 4 החוקים הראשונים דואגים למעבר על הרשת המכסה.
רשומות 5 ו-6 דואגות למעבר על הרשת.
שני החוקים הראשון מתארים את ההתנהגות הדרושה כאשר נכנסת פקטה עם כיוון קדימה ושמטרתה למדוד לינק. החוק הראשון מתמודד עם מקרה שצריך להמשיך ההפצה והשני שלא צריך להמשיך
שני החוקים הבאים דואגים לחזרה דרך הparent portחזרה לMP, כאשר בחוק הראשון נדאג להוסיף תיוג של הswitch ובחוק השני פשוט נשלח ישר חזרה.
שני החוקים האחרונים מתעסקים עם ההפצה, חוק אחד מותקן על כל הלינקים ברשת שהם לא sp ושם למקרה שיש הלוך חזור אז החוק יותקן פעמיים, על הsp עצמו יותקן רק חוק אחד.
Traverse RTPs

23. GRAMI – features summary
Controller is not involved in the measurements
It gets a summary of the results
Any number of MPs in any location
Resource efficient
(n links, r RTPs and k MPs):
Small number of probe packets
Send k, return 𝑛+𝑟
Up to 4+2𝑟 flow entries
𝑚 1
𝑚 2
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
מטרת השקופית:
להסביר מאפיינים חשובים של המערכת.
להגיד:
לאחר הכותרת
למערכת יש כמה מאפיינים שמייחדים אותה.
בולט ראשון – הקונטורולר
הקונטרולר לא מעורב במדידות בכלל אלא רק בשלב הoffline , המדידות יוצאות מהMPs וחוזרים אליהם שם גם נעשה כל עיבוד המידע.
(הנפשה – שליחת שתי הודעות מהMPs והעלות האפליקציה).
בולט שני – כל מספר של MPS.
המערכת יכולה לעבוד ולהתאים את הרשת המכסה לכל מספר של MPs שיכולים להיות ממוקמים בכל מקום שנרצה.
(הנפשה של הוספה של MP)
בולט שלישי – פחות עומס
אנחנו רוצים שהמערכת שלנו לא תוסיף הרבה עומס כדי שלא תשפיע על המדידות, לכן נרצה שמספר נמוך של פקטות מדידה יעברו על הרשת.
(הנפשה של השליחה)
למעשה תשלח הודעה יחידה מכל אחד מהMPs
(הנפשה של פיצול)
בהגעה לswitch הפקטה תתפצל לתשלח לכל הלינקים שיוצאים מהswitch בנוסף לפקטה יחידה שתחזור לMP כדי למדוד את המסלול הכי קצר עד לאותה נקודה.
(הנפשה של תיוג וחזרה ראשונה)
כעת נניח שהפקטות המשיכו להתפשט ברשת, בכל שלב יחזרו חזרה לMPעל אותו מסלו פקטות, הפקטות הסגולות מקווקות מתארות פקטות שמתויגות עם מידע מאיזה switch הן חזרה והפקטות האדומות חוזרות עם מידע שהן חזרו מRTP.
(הנפשה של החזרה אחרונה)
נשים לב שהswitch הראשון בדרך חזור מוסיף מידע נוסף ומחזיר חזרה לMP.
(הנפשה הכנסה של מספרים)
לכן בסך הכל אנחנו שולחים k פקטות מk נקודות מדידה ומקבלים חזרה פקטה אחת לכל לינק ולכל RTP (כל לינק וכל RTP מכוסה פעם אחת בדיוק)
הרחבה
היתרון של שכפול הפקטות היא שהדרך קדימה במסלול משותפת לשני המסלולים הנמדדים וששני המסלולים נמדדים בזמן קרוב יחסית מה שמגדיל את הדיוק לעומת שתי חיסור של שני מסלולים שנמדדו בנפרד ובזמן שונה או לעומת מדידת כל המסלולים במקביל מה שמעמיס על הרשת.
אנחנו מניחים כי תחת תנאים דומים פקטות דומות יחוו RTT דומה. לכן אנחנו מקפידים לשלוח כל הזמן את אותה הפקטה (עד כדי שינוי הpacket ID). לכן עבור טכניקות תזמון מסויימות כמו Virtual output queues או active queue management זמן העיבוד בתוך הqueue עלול להשתנות עבור ingress ports שונים. חשוב לציין כי במקרה כזה אין כל משמעות למדוד RTT של לינק או מסלול ספציפי כי זה מאוד משנה מאיפה נכנס הפקטה ולאן היא יוצאת לאחר מכן.
בולט רביעי
את המדידה של כל הלינקים ושל r RTPs ברשת נוכל לעשות עם 4 חוקים ועוד 2 חוקים לכל אחד מהRTPs. (
(הנפשה שמציגה את הטבלה)
הטבלה שלנו תהיה מורכבת מ4 חוקים שמותקנים על כל switch שמטרתם לייצג את הלוגיקה של הרשת המכסה. לכל RTP יהיו עד שני חוקים נוספים על הswitches במסלול שלו.
Overlay network traversal flow entries
RTP 𝑃 1 traversal flow entries
RTP 𝑃 𝑟 traversal flow entries

24. Related work
RTT measurements in Traditional networks
Tracers
[Francis el al. 2001], [Gummadi el al. 2002]
Network components manipulations
[Augustin el al. 2007], [Pelsser el al. 2013]
Large scale
[Guo el al. 2015]
RTT measurements in OpenFlow networks
Overloading the controller
[Phemius el al. 2013], [Van Adrichem el al. 2014], [Yu el al. 2015], [Agarwal, el al. 2014]
𝑠 1
𝑠 2
𝑠 3
𝑠 4
𝑠 6
𝑠 7
𝑠 5
מה להגיד:
אפשר לחלק את העבודות שעסקו במדידות ברשת ל-2, מדידות בין רשתות (inter-network) ומדידות בתוך הרשת עצמה (intra-network).
כל העבודות שסקרתי וסקו במדידות בין רשתות עבדו תחת האילוצים של הרשתות הקלאסיות ובאו לתת פתרון כאשר אין שליטה על הניתוב ברשת. חלק מהעבודות ניסו ליצור מניפולציות על ההודעות או על רכיבי הרשת בשביל לדאוג שההודעות יעברו ניתוב קונסיסטנטי (לדוגמא paris traceroute שעשה מניפולציה על הפקטות כדי שיעברו בצורה שהוא רצה דרך load balancers) ,בעוד חלק אחר מדבר על דאגה כי הפקטות יעברו דרך נקודות מסויימות ובכך יוכלו לשערך בערך מה המסלול שהן עברו (ID Map שם טרייסרים וking ניצל את הפרוטוקול ההיררכי של DNS בשביל למדוד את הRTT בין שני name servers).
העבודה שלנו כאמור מתמקדת במדידות בתוך הרשת ושם היו יותר עבודות לאחרונה שניסו לנצל את היכולת של OpenFlow וSDN על מנת למדוד מסלולים שונים ברשת. הגישה המרכזית הייתה להשתמש בcontroller וביכולות שלו להזריק פקטות לרשת על מנת למדוד את הRTT של סגמנטים מסויימים. לגישה הזו היו שתי בעיות מרכזיות לטעמי, הראשונה היא כמו שהצגתי הנושא של העומס על הנקודה שממילא הכי עמוסה ברשת (הלא היא הcontroller),
להדגיש כי אין פה גמישות וכי הcontroller הוא גם ככה הנקודה העמוסה ברשת
השנייה היא שאם כבר הוחלט להעמיס על נקודה זו, יצאו מספר מאמרים שהראו כי התוצאות שמגיעות מאוד מאוד רועשות. בנוסף לכך, היו עבודות שניסו למדוד one way delay על ידי שימוש באותה שיטה, הבעיה להם הניחו כי הRTT הוא סימטרי ולמעשה מה שעשו היה לחלק אותו ל-2.

25. Related work - Shibuya at al. [ICN 2014]
GRAMI is more scalable (flow entries, probe packets)
GRAMI can monitor all links and any RTP from any number of MPs
GRAMI vs Shibuya for network with n links and r RTPs
MPs
Probe packets
Flow entries
Measuring
GRAMI
Any k
Send k, return n+r
4+2r
Links and RTPs
Shibuya 1
Send n, return n
O(n)
Links only
מה להגיד:
בעבודה הכי קרובה לשלנו ניסו גם כן למדוד RTT של כל הלינקים ברשת מנקודה יחידה ברשת.
לעבודה שלנו יש מספר יתרונות וחידושים על פני עבודה זו:
אנחנו מסוגלים למדוד מכל מספר של נקודות ברשת לעומת המגבלה של נקודה יחידה.
מספר הפקטות שעוברות על פני הרשת קטן יותר (עד 50 אחוז פחות).
מספר הflow entries שמותקן על גבי הswitches אצלנו הוא קבוע בשביל למדוד את מספר הלינקים ולינארי במספר הRTPs שנרצה לבדוק. ואילו בפתרון שלהם הוא לינארי במספר הלינקים ברשת מה שהופך את הפתרון שלהם ללא סקלאבילי.
אנחנו מאפשרים גם את המדידה של RTPs ואילו הפתרון השני מוגבל למדידה של לינקים בלבד.
לסיכום, הפתרון שלנו נותן גמישות לתעדף בין כמה MPs לתחזק לבין הדיוק שנקבל, מעדיף את הרשת בפחות פקטות מדידה, דורש הרבה פחות flow enries ומאפשר למדוד עם פחות עלות גם לינקים וגם כל מסלול מעגלי שנבחר.

26. Evaluation Worked on Mininet, Cpqd switches with Ryu controller
Real networks topologies (Topology Zoo)
7 to 62 switches
Objectives:
Overhead
Impact of MP’s location
Response to RTT changes
בולט ראשון
סמלצנו את התשתית על mininet עם switches של cpqd עם controller של ryu. כל הלינקים היו עם BW של 100MBPs ו10ms one way delay.
בולט שני
הטופולגיות של הרשתות אותן סמלצנו הן רשתות אמיתיות בגדלים משתנים של בין 7 switches לבין 62 switches. הטופולוגיות היו שונות, meshes , צפופות, עצים וכו'.
בולט שלישי
מטרות המדידה שלנו היו:
רצינו להעריך כמה overhead המערכת שלנו מוסיפה.
רצינו להעריך את ההשפעה של העומק של הלינק הנמדד על התוצאות בכדי להבין האם יש חשיבות לאיך שאנחנו בונים את הרשת המכסה.
רצינו להעריך כמה השפעה יש למיקום נקודות המדידה על התוצאותץ
רצינו להעריך איך המערכת שלנו מגיבה לשינויי, אם היא מצליחה לזהות קריסות ועומסים וכמה זמן זה לוקח לה.

27. Results: overhead Path length increases → Overhead increases
Duplication and tagging in Mininet is relatively long
Mininet(~12𝜇𝑠, ~55𝜇𝑠) , NoviFlow (<4𝜇𝑠, <1𝜇𝑠)
Path of length 2
Path of length 4
לקחנו את התוצאות שקיבלנו מGRAMI על מסלולים מסויימים והשוונו אותן למדידת הדרכים ללא כל תיוג והפצה.
ראינו שהמערכת הוסיפה קצת overhead לתוצאות שגדל עם האורך של המסלול.
עם זאת, אנחנו מניחים שיש כמה גורמים מקלים.
השכפול והתיוג בmininet לוקח הרבה זמן ביחס לswitch אמיתי.
כל הלינקים היו עם אותו הlatency מה שגרם לחזרה באותו הזמן ולעומסים בqueues מה שלא אמור לקרות בדרך כלל.

28. Results: MP’s location
#MPs increases → Overhead and noise decrease
Maintenance vs. accuracy and stability
הגרפים מראים שככל שהשתמשנו ביותר נקודות מדידה, הRTT שנמדד היה נמוך יותר וקרוב יותר לתוצאה האמיתית, משמע ההשפעה של העומס ברשת הייתה קטנה יותר. בנוסף אפשר לראות שהרעש של שהתוצאות הלך וקטן ככל שהשתמשנו ביותר נקודות מדידה.
אני נותן בזמן אונליין לתת דיוק של כמה סדרי גודל.

29. Results: Response to RTT changes
Network overload
Link latency changes, failure and recovery
הגרף השמאלי מראה כי התשתית מצליחה לעקוב אחרי שינויים בlatency של הלינק הנמדד ואם הוא קורס היא יודעת לזהות זאת
הגרף הימני מראה שכאשר יש עומסים פתאומיים על הרשת, התשתית תדע לתת אינדיקציה לכך.

30. Summary and conclusions.
GRAMI
Granular
Efficient and scalable
Monitoring the entire network from few MPs
Any RTP
vSwitch will enable RTT measurements between switches and other network entities (servers)
OpenFlow → Innovation
בולט ראשון
הצגנו את GRAMI, תשתית גראנולרית למדידת RTT שמנטרת את הRTT של כל הלינקים כל המסלולים המעגליים ברשת.
התשתית היא גרנולריות ומאפשרת למדוד RTT ברזולוציה גבוהה יותר.
התשתית יעילה מאוד במשאבים ולכן מאפשרת scalability
המשתמש צריך להחליט כמה MPs הוא רוצה לתחזק מתוך הבנה שככל שיהיו לו יותר MPs אז הוא יהיה גמיש ויותר
העבודה מחדשת בכך שהיא מאפשרת למדוד כל מסלול מעגלי שנרצה מבלי שנשב באחד מנקודות הקצה שלו.
בולט שני
אם נתקין vSwitches על נקודות קצה או middleboxes בתוך הרשת, נוכל למעשה למדוד את הRTT של לינקים ומסלולים לא רק בין כל שני switches ברשת אלא למעשה בין כל שתי ישויות שהן switch או שמותקן עליהן vSwitch
בולט שלישי
openflow נותן לעשות דברים בצורה פשוטה יעילה ואלגנטית יותר, פותח אפשרויות לחדשנות.

31. Questions
Thank you
for listening