Transport layer protocols The objectives of a transport layer protocol include the setting up of an end-to-end connection, end-to- end delivery of data packets, flow control, and congestion control. At transport layer TCP and UDP are two protocols. Which transport layer protocol? TCP dominates in wired Internet with the traffic share in between 80% -90%. It is characterized by the following properties: TCP is reliable; TCP incorporates congestion control mechanism; TCP incorporates end-to-end flow control mechanism.

Transport layer protocols These traditional wired transport layer protocols are not suitable for ad hoc wireless networks due to the inherent problems The following observations can be made concerning ad-hoc networks: it is preferable to seamlessly integrate TCP in ad- hoc networks: -to enable seamless operation of higher layer protocols such as FTP, SMTP, HTTP. if not, to make as less modifications to TCP as possible: if not, to split the TCP into wireless and wired part:

ISSUES IN DESIGNING A TRANSPORT LAYER PROTOCOL FOR AD HOC WIRELESS NETWORKS Induced traffic: - Ad hoc wireless networks utilize multi-hop radio relaying. - In a path having multiple links, transmission at a particular link affects one upstream link and one downstream link. - This traffic at any given link (or path) due to the traffic through neighboring links (or paths) is referred to as induced traffic.

ISSUES IN DESIGNING A TRANSPORT LAYER PROTOCOL Induced throughput unfairness: - This refers to the throughput unfairness at the transport layer due to the throughput/delay unfairness existing at the lower layers such as the network and MAC layers. Separation of congestion control, reliability, and flow control: - A transport layer protocol can provide better performance if end-to-end reliability, flow control, and congestion control are handled separately.

ISSUES IN DESIGNING A TRANSPORT LAYER PROTOCOL Power and bandwidth constraints: - The performance of a transport layer protocol is significantly affected by these constraints. Misinterpretation of congestion: - Traditional mechanisms of detecting congestion in networks, are not suitable for detecting the network congestion in ad hoc wireless networks. - This is because of the location-dependent contention, hidden terminal problem, packet collisions, mobility of nodes, lead to packet loss in ad hoc wireless networks - Hence, interpretation of network congestion as used in traditional networks is not appropriate in ad hoc wireless networks.

ISSUES IN DESIGNING A TRANSPORT LAYER PROTOCOL Completely decoupled transport layer: - the interaction with the lower layers - In ad hoc wireless networks, the cross-layer interaction between the transport layer and lower layers such as the network layer and the MAC layer is important to adapt to the changing network environment Dynamic topology: - Due to the mobility of nodes the deployment scenarios of ad hoc wireless network rapidly changes

DESIGN GOALS OF A TRANSPORT LAYER PROTOCOL The protocol should maximize the throughput per connection. It should provide throughput fairness across contending flows. The protocol should incur minimum connection setup and connection maintenance overheads. The transport layer protocol should have mechanisms for congestion control and flow control in the network.

DESIGN GOALS OF A TRANSPORT LAYER PROTOCOL It should be able to provide both reliable and unreliable connections as per the requirements of the application layer. The protocol should be able to adapt to the dynamics of the network such as the rapid change in topology and changes in the nature of wireless links from uni-directional to bidirectional or vice versa One of the important resources, the available bandwidth, must be used efficiently.

DESIGN GOALS OF A TRANSPORT LAYER PROTOCOL The protocol should be aware of resource constraints such as battery power and buffer sizes and make efficient use of them. The transport layer protocol should make use of information from the lower layers in the protocol stack for improving the network throughput. It should have a well-defined cross-layer interaction framework for effective,scalable, and protocol-independent interaction with lower layers. The protocol should maintain end-to-end semantics

CLASSIFICATION OF TRANSPORT LAYER SOLUTIONS

A Brief Revisit to Traditional TCP TCP is a reliable, end-to-end, connection- oriented transport layer protocol that provides a byte-stream-based service i.e the stream of bytes from the application layer is split into TCP segments, the length of each segment is limited by a maximum segment size (MSS) TCP regulates the number of packets sent to the network by expanding and shrinking the congestion window.

A Brief Revisit to Traditional TCP TCP Tahoe congestion control Every transmission starts with connection setup and followed by slow start phase: the sender starts the session with a congestion window set to maximum segment size (MSS): - it sends MSS bytes of data; - starts retransmission timeout (RTO) and waits for acknowledgement packet (ACK). if ACK is received in RTO the congestion window is doubled and two MSSs of data are sent; the congestions window is doubled with every ACK until it reaches slow-start threshold;

TCP Tahoe congestion control

A Brief Revisit to Traditional TCP The slow-start phase is followed by congestion avoidance phase: when the slow-start threshold is reached, the congestion window grows linearly Once it reaches the slow-start threshold it grows linearly, adding one MSS to the congestion window on every ACK received This linear growth, which continues until the congestion window reaches the receiver window is called congestion avoidance

A Brief Revisit to Traditional TCP

If the ACK packet does not arrive within the RTO period, then it assumes that the packet is lost TCP assumes that the packet loss is due to the congestion in the network and it invokes the congestion control mechanism. TCP sender does the following during congestion control: -reduces the slow-start threshold to half the current congestion window or two MSSs whichever is larger - resets the congestion window size to one MSS - activates the slow-start algorithm, - resets the RTO with an exponential back-off value which doubles with every subsequent retransmission

A Brief Revisit to Traditional TCP

TCP Tahoe with fast retransmit Scheme TCP Tahoe uses the fast retransmit procedure to respond to losses: - The TCP sender also assumes a packet loss if it receives three consecutive duplicate ACKs (DUPACKs) - Upon reception of three DUPACKs, the TCP sender retransmits the oldest unacknowledged segment

TCP Tahoe with fast retransmit Scheme

TCP Reno TCP Reno is similar to TCP Tahoe with fast recovery On timeout or arrival of three DUPACKs, the TCP Reno sender enters the fast recovery and performs the following actions; - retransmits the lost segment and does not enter slow start phase -reduces the slow-start threshold to 1=2 of the current CW - reduces the CW to a 1=2 of the current CW + 3 Increases the CW linearly with reception of subsequent DUPACKs;

TCP Reno on reception of ACK the sender: -resets the CW with the slow-start threshold -enters the congestion avoidance similar to TCP Tahoe. More improvements are available: TCP NewReno; TCP SACK.

Fast recovery procedure of TCP Reno.

Why does TCP not perform well in ad- hoc networks? The following reasons are behind the poor performance of TCP in ad-hoc networks: Misinterpretation of packet loss: -wired networks: packets losses are mainly due to congestions; - ad-hoc wireless networks: high packet loss due to: - high BER -collisions due to hidden terminal problem -frequent path breaks: mobility

Reasons behind the poor performance of TCP in ad-hoc networks: Frequent path breaks: - Frequent path path breaks : topology changes, route reconfigurations; - RouteReconf. = f(Number of node, Tx, topology, bandwidth, traffic, nature of routing); - If RouteRecong. > RTO: TCP enters a slow start phase; - Slow start: inefficient use of the resources

Reasons behind the poor performance of TCP in ad-hoc networks: Effect of path length: - It is found that the TCP throughput degrades rapidly with an increase in path length

Reasons behind the poor performance of TCP in ad-hoc networks: Misinterpretation of congestion window: -the congestion control mechanism is invoked when the network gets partitioned or when a path break occurs. - When the route is reconfigured, the congestion window may not reflect the transmission rate acceptable to the new route, as the new route may actually accept a much higher transmission rate.

Reasons behind the poor performance of TCP in ad-hoc networks: Asymmetric link behavior: -The directional links can result in delivery of a packet to a node, but failure in the delivery of the acknowledgment back to the sender. -It is possible for a bidirectional link to become uni-directional for a while. This can also lead to TCP invoking the congestion control algorithm and several retransmissions.

Reasons behind the poor performance of TCP in ad-hoc networks: Uni-directional path: -both DATA and ACK require RTS-CTS-DATA-ACK at the data-link layer; -contention for resources in the same link at forward and backward paths; - this contention may not be the same.

Reasons behind the poor performance of TCP in ad-hoc networks: Multipath routing: -Some routing protocols use multiple paths between the source and destination leading to: -high number of out-of-order packets leading to DUPACKs; - different RTO values leading to unnecessary retransmissions.

Reasons behind the poor performance of TCP in ad-hoc networks: Network partitioning and remerging:

Feedback-Based TCP(TCP-F) TCP-F requires the following to enhance performance: support of reliable data-link layer protocols; routing support to inform the TCP sender about path breaks; routing protocol is expected to repair the broken path within a reasonable time. The aim of TCP-F: minimize the throughput degradation resulting from path breaks.

Feedback-Based TCP(TCP-F) In TCP-F an intermediate node upon detection of the link break: obtains information from TCP-F sender's packets routed via this node; generates a route failure notification (RFN) packet; routes this packet to the TCP-F sender; does not forward any packet from this connection; updates its routing table; stores information about generation of a RFN packet.

Feedback-Based TCP(TCP-F) Any intermediate node that forwards the RFN packet: if this node has an alternative route to destination: - discards the RFN packet and uses this path to forward other packets: - this allows to reduce an overhead involved in route re-establishment if this node does not has alternate route to destination: -updates its routing table and forwards the RFN packet to the source.

Feedback-Based TCP(TCP-F) When TCP-F sender receives the RFN packet it enters the so-called snooze state: stops sending packet to the destination; cancels all the timers; freezes the congestion window; sets up a route failure timer = f(routing protocol, network size, network dynamic): when failure timer expires TCP-F enters the connected state.

Feedback-Based TCP(TCP-F) If the broken links rejoins or intermediate node obtains a new path to destination: route reestablishment notification (RRN) is sent to TCP-F sender; When the sender receives RRN packet: reactivates all timers and congestion window assuming that the network is back; starts transmitting data available in the buffer; takes care of packets lost due to path break

Feedback-Based TCP(TCP-F)

Advantages and Disadvantages TCP-F provides a simple feedback-based solution to minimize the problems arising out of frequent path breaks TCP congestion control mechanism is used to respond to congestion requires merging of transport and network layer features (at least, cross-layering); requires ability of nodes to detect path breaks; requires ability of routing protocols to repair a link within a reasonable time; requires ability of node to determine the TCP-F sender;

TCP with explicit link failure notification (TCP- ELFN) According to TCP-ELFN an explicit link failure notification is used When an intermediate node detects a link failure: sends an explicit link failure notification (ELFN) to TCP-ELFN sender: - either sending an ICMP destination unreachable message ; - or inserting info regarding link break in RouteError message of the routing protocol.

TCP-ELFN Once the TCP-ELFN sender receives the ELFN packet: it disables its retransmission timer and CW; enters a standby state. Being in standby state the TCP-ELFN sender: In this state, it periodically originates probe packets to see if a new route is reestablished. when ACK for a probe packet is received TCP-ELFN continues to perform as usual.(it leaves the standby state, restores the retransmission timers, and continues to function as normal)

TCP-ELFN

Advantages and Disadvantages provides path break information to the sender; does not heavily depend on routing protocol capabilities; The disadvantages of TCP-ELFN include the following: when the network is temporarily partitioned, the path failure may last longer and this can lead to the origination of periodic probe packets consuming bandwidth and power the congestion window used after a new route is obtained may not reflect the achievable transmission rate acceptable to the network and the TCP receiver.