פייסבוק
Facebook Pagelike Widget
פרסומת

TCP ב- Wireless

 

TCP ב- Wireless


בעולם האלחוטי יש יותר סיכוי שהשידור לא יצליח ( התנגשויות ) בניגוד לחוטי שבו הבעיות העיקריות הם ניתוב לא נכון, עומס הנתב שלא מצליח להתמודד וכו'..
מכיוון שיש הרבה יותר התנגשויות באלחוטי יכול להיות מאוד שה-
Timeout יגמר בעקבות עומס ברשת.


אינני יודע גם את מספר המשתמשים שיהיו לי ברשת בשליחה הבאה.


 


שיטה 1


ב-TCP התעבורה עוברת ישירות בין 2 נקודות. אך באלחוט יש את ה-AP שצריך לפצל את הקשר בין המקור ל-AP ומה-AP אל היעד. ברגע שה-AP מקבל הודעה הוא מחזיר ACK לשולח, שומר ב-Buffer את ההודעה ומעביר את ההודעה הלאה.

תחנת היעד עדיין חושבת שהמקור שלח אליה. היא לא יודעת שזה הגיע מה-AP.


מעבר בין AP-ים בזמן השידור
כאשר אני מזהה שאני עומד לעבור ל-AP חדש, התחנה אומרת לAP הישן שיש לה Receiving Window בגודל 0 ( כלומר שאי אפשר לשלוח ) והתחנה יכולה לעשות Force Retransmission :


הוצאת מספר ACK-ים על מנת לשכנע את הצד השני שקרה Duplicate ACK והצד השני יעשה
Fast Retransmission ( ישלח את המידע מחדש )


 


שיטה 2


אני לא פוגע ב-TCP ( קשר מנקודה לנקודה ) אבל אני מבקש מה-AP לעשות "רחרוח" במידה שיש Dup ACK ( גם שומר וגם עוקב אחרי ACK-ים שחוזרים )


 




The basic assumption behind TCP is that packets are lost due to congestion, and that transmission errors are very rear. This is not true for Wireless networks.


In wireless, packet loss does not necessarily indicate congestion. Therefore congestion window should not be decreased.


 


 Mobility may change the connection quality. Need to adjust congestion window according to the changing connection quality.


 


Improvement suggestions


( מתוך מחקר בנושא של סטודנטים מהטכניון )


1.     Number of duplicate  acks


  • Current situation: the default value in TCP is 3. 

  • Possible Problem: in mobile Ad-Hoc networks the default value may be improper due to the mobility of each node.

  •  Possible solution I:  increase the number of duplicate acks. This solution helps in a following scenario:  a source sends packets in some route and because of the network mobility the packets don’t arrive in the same order, which were sent in. Increasing the number of duplicate acks may save the retransmission of the “late arriving” packets. (This change comes along with bigger starting window).

  • Possible solution II:  decrease the number of duplicate acks. In a high bit error rate network such as a wireless network, waiting for large number of duplicate acks, may cause the sender entering to a deadlock resolved by a timeout (because of packets lost and a small sending window). And this scenario could be prevented if the number of duplicate acks was smaller.


 


2.     Starting window size


  • Current situation: starting window is 1.

  • Possible Problem: we assume that in this type of networks (high bit error rate situation), most of the time the TCP connections will be in the slow start, after a timeout, and the starting window is the sender’s opportunity to send as much data as he can. (“Aggressive start mode”).

  • Possible solution: increasing the starting window size.


3.     Timeout


  • Current situation: timeout is A+4D.

  • Possible Problem: as we mentioned before there is a high probability to get into a timeout. Because of this fact the TCP performance is damaged.

  • Possible solution: adapt a better calculation for the timeout.


 


4.     Delayed  ack


  • Current situation: this option is by default not in use.

  • Possible improvement: On mobile ad hoc networks the situation is quite fragile. For example in a short time one node can be the main router for the entire network, in those situations congestion is almost unavoidable. Taking into consideration the quite high bit error rate leads to lots of packets that are


re-sent. A possible solution to the problem we have just described is using the delayed ack option. In this way we can reduce congestion and the lost packet rate.


 


5.     Using selective  ack


  • Current/Popular situation: selective acks is not in use.

  • Possible problem: Due to high bit error rate in ad hoc mobile network, there is quite high probability that some of the packets from the same sending window will be corrupted/lost. If selective ack option is not used, a large amount of packets will be send again although arrived to the destination successfully. This can lead to an absurd situation – making out best effort to send over and over a set of packets that some of them already arrived to the destination and were discarded.

  • Possible solution: By using selective ack option we can ensure packets that were received by the destination successfully, will not be send again. By taking this act, congestion is reduced and therefore throughput increases.

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

*

צ\'אט
  • אמא של נריה ההומו מוצץ בתחת
    נריה יא גיי
    2 August 2020
  • אמא של דימיטרי הגיי שוב
    לך זדיין לא יודעת למה ילדתי אותך תחזור לכוס שלי
    2 August 2020
  • אמא של דימה
    שתוק שתוק יא בן תן למה לפני שאני בא לרמלה מזיין את הכוס של האמ אמא שלך יא בן של זונה מזדיין בתחת . לך לך יא חרא אל תדבר איתי אפילו יא זין בטוסטר אמן יתקע לך זין במאורר תקרה נודרררר
    2 August 2020
  • Beni Goren
    mon deu grigory
    2 August 2020
  • אמא של נריה ההומו
    נריה בני היקר, אם לא היית הילד שלי נודרת הייתי עושה אותך ואגב לדניאל עומד עלייך
    2 August 2020
  • Beni Goren
    priviet
    2 August 2020
  • אמא של גבריאל ההומו
    גבריאל יא הומו גינגי קוקסינל מוצץ בובלולים גיי פידר גבנו
    2 August 2020
  • אמא של דימה
    דימה קוקסינל שמו, אמן יהיה לו זין יא ילדה חרתה
    2 August 2020
  • Beni Goren
    מיאו מיאו
    2 August 2020
  • עומד לי אחושרמוטה
    געע
    30 June 2020
Your Shout