Supervisor: Kaisa Sere
TCP within the Ad Hoc Network – TCP BuS
Download 298.62 Kb.
|
- Navigate this page:
- 4.3.1Domain Name Service
4.3 TCP within the Ad Hoc Network – TCP BuSIf a link on which a fixed TCP connection is active breaks, the flow control algorithm of the sender will deduce that it is overrunning the intermediate routers and slows down its operation. This will cause momentary degradation in throughput when the connection is restored. Nodes running TCP-BuS [Kim+01] can report link breakage, with help of a feedback utility (TCP-F [Chandran+98]), by letting an intermediate node between the sender and its destination, report breakage in the route with Route Failure Notification (RFN) messages. Upon receiving a RFN from the upstream node the sender enters a snooze state, halting all transmission, freezing timers and the congestion window (explained below). The receiver also starts a Route Failure timer, which indicates a time limit for route repair when firing. Meanwhile, the reporting node tries to find another route for the packets. When succeeding with the route repair it notifies the sender with a Route Re-establishment Notification (RRN). In figure 4-1 failure point node 3 detects link breakage and sends RFN to node 2, which forwards it to the active sender 1. Both will invalidate the particular route. Node 1 freezes and waits for RRN. When node 3 repairs the route through node 5 and sends a RRN then sender 1 resumes transmission. 
Fig. 4 13: Detection of link breakage. Messages are enumerated chronologically. When resuming transmission because of an expiring timer it will be done in a way inherited from versions Tahoe and Reno of TCP called slow start and congestion avoidance, described in [Stevens97] and developed by van Jacobsen. In this scheme a congestion window (cwindadvertised window, which relates to the buffering capabilities of the receiver) is added to the algorithm which calculates the remaining buffering resources of the network (intermediate routers). The sender assesses this by using ACK timeout or multiple ACKs as indicators. After packet loss the congestion window is set to one and then opening the window almost exponentially after every acknowledgement. Figure 4-2 shows how the congestion window expands: At the beginning cwind is 1, allowing 1 segment to be sent and acknowledged. This allows cwind to expand to 2 and two segments are sent. When these two segments are acknowledged cwind expands to 4 and so on. 
Fig. 4 14: Cwind expansion. The sender is therefore limited to sending no more segments than the two mentioned windows specifies. TCP’s congestion control includes in addition to slow start, a scheme called congestion avoidance. This means that whenever congestion occurs, the cwind is set to half and the increase after that depends on whether TCP is performing slow start or congestion avoidance. Another variable needs to be introduced in order to determine this and that is ssthresh, which is initially set to 65535 bytes. If cwind is less than or equal to sstresh, TCP is in slow start, otherwise congestion control is taking place. If slow start is going on, it will continue until reaching cwind, which was set to half when congestion occurred. At this time the congestion avoidance takes over, which imposes a linear increase every time a segment is acknowledged. TCP-BuS takes the segment partition of TCP-I (wired and last-hop wireless segment) and extends the wireless partition to support ad hoc networking and distributed congestion control - TCP-BuS lists the following enhancements [Toh02]: (1) Explicit notifications, which work in the same way as RFN-RRN in TCP-F, except here they are called Explicit Route Disconnection Notification (ERDN) and Explicit Route Successful Notification (ERSN). The nodes that wait for route repair upstream of the node that detected the failure point (FP), will upon receiving an ERDN, use (2) extended timeout values for the buffered packets destined for the unavailable source. (3) Selective retransmissions requests can be made to the source before their timeout values expire. A scheme for (4) avoiding unnecessary requests for fast retransmission has also been included. The destination node has the ability to request retransmission of lost packets. This requires the destination to continue to send acknowledgements indicating the expected packet sequence number since TCP-Reno will retransmit segments of which duplicate ACKs are received. TCP-BuS implements (5) reliable transmission of control messages by sensing that per-hop transmissions actually are successful. The per-hop reliability can be achieved by letting the sender “overhear” that the receiver has forwarded the packet to a third node. Explicit acknowledgements may also be used. Additional reliability can be provided by letting the source send so-called PROBE query messages to the FP to inquire if the route has already been repaired. In [Kim+01] the reported simulations of TCP-BuS were performed by letting it run on top of the routing protocol called Associativity Based Routing (ABR). ABR was altered to handle the TCP control messages i.e. these are integrated into the ABR routing messages. When beginning transmission TCP-BuS uses slow start until an ERDN is received. When this happens, activity is frozen. The ERDN message contains the last segment that the PN could not send due to breakage (ERDN_GEN_SEQ). Also, the last segment sent by the source (ERDN_RCV_SEQ) before it received an ERDN. When the route is repaired by the PN, i.e. the PN receives a REPLY from the destination - the PN can from this extract the last segment received by the destination (LAST_ACK). The PN copies this value to the ERSN and sends it to the source. Since the PN also sends an RN to the source it also invalidates the route and flushes the buffered packets. The source can then correctly assume that LAST_ACK + 1 to ERDN_GEN_SEQ -1 were discarded by the network. As an example let us say that: ERDN_GEN_SEQ=15, ERDN_RCV_SEQ=20, LAST_ACK=10 Then, the source knows that the segments 15 to 20 are buffered at the PN and will be transmitted at reconnection to the destination. When the ERSN with the LAST_ACK arrives at the source it can deduce that messages 11 to 14 has to be retransmitted, since they are guaranteed to be discarded. The results of [Kim+01] were gotten with a simulator with the following settings. The network and transport layers were modeled assuming fixed nodes with 50m of omnidirectional radio range, randomly failing links, and a transmission data rate of 19.2Kbps. The segment size was set to 640 bytes. Since the simulator simulates mobility by disconnecting links randomly and not because of node movement it will not capture all phenomena found in the real world. For instance, when two nodes move in the same direction with the same speed and the distance is barely small enough to keep the link up, can cause oscillations in the routing protocol, especially in proactive protocols. This is because the link goes up and down time after time causing many control messages to be sent. In any case, the simulator provides a fair basis for all the tested transport protocols. First, they examine what kind of effects the route lengths have on the delivery rate of packets (congestion ignored). In this test TCP-BuS shows, on average 15% to 30% better delivery rate than TCP and TCP-F as the routes grow from 0 to 18 hops. The following test was done to evaluate the delivery rate with respect to the frequency of link failure. Here randomly chosen links are congested for a period of 10 seconds. TCP-BuS outperforms the other two by 10% to 30% on average. It is also clear from the test that TCP performs significantly poorer then the other two since it invokes its congestion control procedures and stays in idle state for a shorter period after breakage occurs. In the third test they measured the delivery rate in increasing congestion durations and found that the selective retransmission mechanism helped in improving the delivery rate and again TCP-BuS outperforms the other protocols. Among other tests, the segment sequence numbers were observed at the source with anticipated outcome. TCP continued to transmit after link breakage causing extensive retransmissions of the same segments. 4.3.1Domain Name ServiceThe section above solves the Internet connection problem, but we would also like to use textual IP addresses. As with static Internet, the users do not want to remember numeral addresses and the same goes for ad hoc Internet. Providing textual addresses is slightly harder in ad hoc networks, as this is the case with many things in these kinds of networks. When a fixed Internet node is passed a textual address, it first contacts a domain name server which has a textual-to-numeral address reference table. The DNS server passes the numeral address back to the node which can then contact the intended node. In ad hoc networks we cannot assume that a node will always be present in the network. This is why we cannot rely on a DNS server to be present either. An idea that came to our mind was to intertwine the lookup of IP addresses with the routing functions. IP uses numeral addresses for the purposes of routing in the ad hoc network, but textual IP address could be included in discovery messages (reactive protocols) or in the updates (modified RIP). This would enable every node to learn the textual name of every other node and facilitate a local DNS reference table. When the textual addresses are added to the route requests or updates, it is clear that they will increase in size. It is at least certain that a distributed scheme has to developed as no single node can be relied on to always be reachable. It will remain to be seen whether such applications are required between ad hoc nodes that textual addresses are needed. If not, the solution is simple. The only purpose of TCP/IP is to provide access to the Internet then a stationary DNS server will suffice since the gateway to the Internet is stationary anyway. Download 298.62 Kb. Share with your friends:
|