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.