Mobile Networks: TCP in Wireless Networks


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mobile Networks: TCP in Wireless Networks

  1. 1. Lecture 11 Mobile Networks: TCP in Wireless Networks Wireless and Mobile Systems Design
  2. 2. Lecture Objectives <ul><li>Describe TCP’s flow control mechanism </li></ul><ul><li>Describe operation of TCP Reno and TCP Vegas, including congestion avoidance (congestion control), slow start, and fast retransmission and recovery mechanisms </li></ul><ul><li>Describe performance problems of TCP in wireless networks </li></ul><ul><li>Summarize proposed schemes to overcome performance limitations of TCP in wireless networks </li></ul>
  3. 3. Agenda <ul><li>TCP overview </li></ul><ul><ul><li>Flow control </li></ul></ul><ul><ul><li>Congestion avoidance, slow start, and retransmission </li></ul></ul><ul><ul><li>TCP Reno and TCP Vegas </li></ul></ul><ul><li>TCP in wireless networks </li></ul><ul><li>Solutions to TCP performance problems in wireless networks </li></ul>
  4. 4. TCP Flow Control <ul><li>TCP inherently supports flow control to prevent buffer overflow at the receiver </li></ul><ul><ul><li>Useful for fast sender transmitting to slower receiver </li></ul></ul><ul><li>Receiver advertises a window ( wnd ) in acknowledgements returned to the sender </li></ul><ul><li>Sender cannot send more than wnd unacknowledged bytes to the receiver </li></ul>Src Dest Limits amount of data that destination must buffer
  5. 5. TCP Flow Control Example Sender Receiver wnd = 1200 500 bytes 500 bytes wnd = 200 200 bytes wnd = 500 500 bytes
  6. 6. Flow Control Can Limit Throughput (1) <ul><li>Let rtt be the round-trip time, i.e., the time from sending a segment until an acknowledgement (ACK) is received </li></ul><ul><li>Let t = wnd / b be the time to transmit a full “window” of data, where b is link bandwidth </li></ul>Sender Receiver t rtt wnd bytes
  7. 7. Flow Control Can Limit Throughput (2) <ul><li>For a link with a high delay-bandwidth product ( rtt  b ), the flow control window can limit throughput for the connection </li></ul><ul><ul><li>In this case, t  rtt </li></ul></ul><ul><ul><li>Throughput is wnd / rtt </li></ul></ul>Sender Receiver t rtt wnd bytes
  8. 8. TCP Congestion Avoidance <ul><li>Congestion avoidance (control) was added to TCP in an attempt to reduce congestion inside the network </li></ul><ul><li>A much harder problem … </li></ul><ul><ul><li>Requires the cooperation of multiple senders </li></ul></ul><ul><ul><li>Must rely on indirect measures of congestion </li></ul></ul><ul><li>Implemented at sender </li></ul>Src Dest Attempts to reduce buffer overflow inside the network
  9. 9. Recent History of TCP <ul><li>TCP has been improved over the years </li></ul><ul><ul><li>More robust estimates of round-trip time </li></ul></ul><ul><ul><li>Faster recovery from packet loss </li></ul></ul><ul><ul><li>Congestion avoidance and improvements </li></ul></ul><ul><li>TCP Reno </li></ul><ul><ul><li>Developed by Van Jacobsen in 1990 </li></ul></ul><ul><ul><li>Improvement to TCP Tahoe (1988) </li></ul></ul><ul><ul><li>Added fast recovery and fast retransmit </li></ul></ul><ul><li>TCP Vegas </li></ul><ul><ul><li>Developed by Brakmo and Peterson in 1995 </li></ul></ul><ul><ul><li>New congestion avoidance algorithm </li></ul></ul>
  10. 10. TCP Operation <ul><li>Flow control (already discussed) </li></ul><ul><li>Congestion avoidance </li></ul><ul><ul><li>Introduce a congestion window ( cwnd ), in addition to flow control window ( wnd ) </li></ul></ul><ul><ul><li>Need to manage size of congestion window </li></ul></ul><ul><li>Slow start </li></ul><ul><ul><li>Aggressively grow congestion window until congestion is detected </li></ul></ul><ul><ul><li>In Reno, aggressively reduce rate when invoked </li></ul></ul><ul><li>Loss detection and retransmission </li></ul><ul><ul><li>Fast retransmission and recovery </li></ul></ul><ul><ul><li>Less severe adjustment congestion window size </li></ul></ul>
  11. 11. Congestion Avoidance: TCP Reno (1) <ul><li>TCP can maintain a congestion window size, cwnd , at the sender </li></ul><ul><ul><li>Sender can transmit up to minimum of cwnd and wnd bytes </li></ul></ul><ul><li>TCP Reno uses packet loss as an indicator of network congestion </li></ul><ul><ul><li>Most packet loss occurs due to congestion at intermediate routers since IP has no congestion control mechanism </li></ul></ul><ul><ul><li>Packet losses due to bit errors are rare </li></ul></ul><ul><li>TCP Reno is reactive with respect to congestion </li></ul><ul><ul><li>Responds to loss of packets indicated by timeout or duplicate ACKs </li></ul></ul>
  12. 12. Congestion Avoidance: TCP Reno (2) <ul><li>When packet loss occurs, congestion window size is reduced </li></ul><ul><ul><li>Due to timeout: cwnd = 1 and enter slow start </li></ul></ul><ul><ul><li>Due to duplicate ACKs: cwnd = cwnd /2 + 3  segment_size </li></ul></ul><ul><li>Congestion window size is increased when data is successfully acknowledged </li></ul><ul><ul><li>Slow start </li></ul></ul><ul><ul><ul><li>Slow start active if cwnd  ssthresh (threshold) </li></ul></ul></ul><ul><ul><ul><li>During slow start, congestion window increased by segment_size for every ACK received  opens the window exponentially </li></ul></ul></ul><ul><ul><li>Congestion avoidance </li></ul></ul><ul><ul><ul><li>cwnd = cwnd + (1/ cwnd ) + segment_size /8 for every ACK received  additive growth in window size (about one segment every round trip time) </li></ul></ul></ul>
  13. 13. Congestion Window in TCP Reno G. Xylomenos, G. C. Polyzos, P. Mahonen, and M. Saaranen, “TCP Performance Issues over Wireless Links,” IEEE Communications Magazine , Vol. 39, No. 4, pp. 52-58, April 2001.
  14. 14. Congestion Avoidance: TCP Vegas (1) <ul><li>Sets congestion window size based on difference between the expected and actual data rates </li></ul><ul><ul><li>Goal is to control the number of outstanding bytes in queues in the network (i.e., the backlog in queue) </li></ul></ul><ul><li>Define… </li></ul><ul><ul><li>cwnd : Current congestion window size </li></ul></ul><ul><ul><li>rtt* : Minimum (“congestion-free”) round-trip time </li></ul></ul><ul><ul><li>rtt : Actual (with congestion) round-trip time </li></ul></ul><ul><ul><li>diff : Estimated backlog in queue </li></ul></ul><ul><ul><li> : low threshold for diff (want diff >  ) </li></ul></ul><ul><ul><li> : high threshold for diff (want diff <  ) </li></ul></ul><ul><li>diff = ( cwnd / rtt* – cwnd / rtt )  rtt * </li></ul>
  15. 15. Congestion Avoidance: TCP Vegas (2) <ul><li>Estimated backlog in queue (repeated here) </li></ul><ul><ul><li>diff = ( cwnd / rtt* – cwnd / rtt )  rtt * </li></ul></ul><ul><li>TCP Vegas attempts to keep at least  bytes, but fewer than  bytes, in queue </li></ul><ul><ul><li>If diff <  , increase cwnd by 1 </li></ul></ul><ul><ul><li>If diff >  , decrease cwnd by 1 </li></ul></ul><ul><ul><li>Otherwise (   diff   ), cwnd is not changed </li></ul></ul><ul><li>TCP Vegas provides a proactive response to congestion </li></ul><ul><ul><li>Congestion window changed gradually as observed backlog (delay) changes </li></ul></ul>
  16. 16. Congestion Avoidance: TCP Vegas (3) cwnd+  Linearly Increasing cwnd+  cwnd C Expected Throughput Actual Throughput Linearly Decreasing  /rtt  /rtt Throughput Window Size
  17. 17. Slow Start Mechanism <ul><li>The goal of the slow start mechanism is to detect and avoid congestion as a connection begins or after a timeout </li></ul><ul><ul><li>Slow start threshold ( sshtresh ) set to half of cwnd when congestion is detected </li></ul></ul><ul><ul><li>Slow start is active if cwnd  ssthresh </li></ul></ul><ul><ul><li>Initially, cwnd = 1 segment </li></ul></ul><ul><li>TCP Reno doubles the congestion window every round-trip time if no loss occurs </li></ul><ul><li>TCP Vegas doubles the congestion window every other round-trip time if no loss occurs </li></ul>
  18. 18. Loss Detection: TCP Reno <ul><li>Coarse-grain timeout indicates packet loss </li></ul><ul><ul><li>Sender starts a timer when TCP segment is sent </li></ul></ul><ul><ul><li>Timeout occurs if ACK not received before timeout </li></ul></ul><ul><ul><li>Retransmission occurs </li></ul></ul><ul><ul><li>Slow start is invoked (big reduction in rate!) </li></ul></ul><ul><li>Three duplicate ACKs indicate packet loss </li></ul><ul><ul><li>Receiver required to send an ACK if it receives an out of order segment – a segment may be out of order or lost </li></ul></ul><ul><ul><li>Sender assumes loss when it receives three duplicate ACKs </li></ul></ul><ul><ul><li>Fast retransmission and recovery mechanism – retransmit the requested segment (which is presumed lost after three duplicate ACKs) without waiting for a timeout </li></ul></ul><ul><ul><li>Congestion avoidance (smaller reduction in rate) </li></ul></ul>
  19. 19. Loss Detection: TCP Vegas <ul><li>Coarse-grain timeout mechanism </li></ul><ul><ul><li>Same as for TCP Reno </li></ul></ul><ul><li>Fine-grain timeout mechanism </li></ul><ul><ul><li>If a duplicate ACK is received and the round-trip time of the first unacknowledged segment exceeds the fine-grain timeout value, then segment loss is assumed and requested segment is retransmitted </li></ul></ul><ul><ul><li>If a non-duplicate ACK is received after a retransmission and the round-trip time of the segment exceeds the fine-grain timeout value, then segment loss is assumed and retransmission occurs </li></ul></ul>
  20. 20. TCP Reno Behavior cwnd  cwnd /2 + 3 time cwnd SS CA SS CA CA Duplicate ACK  CA SS: Slow start CA: Collision avoidance cwnd  1 Timeout  SS
  21. 21. TCP Vegas Behavior <ul><li>Converges more smoothly … assuming sufficiently large buffers </li></ul>SS time cwnd CA
  22. 22. TCP Reno Pros and Cons (1) <ul><li>TCP Reno benefits </li></ul><ul><ul><li>Simple bandwidth estimation scheme </li></ul></ul><ul><ul><li>Aggressive congestion avoidance mechanism ensures bandwidth when connected to TCP Vegas connections </li></ul></ul><ul><ul><li>More widely deployed, probably due to its maturity and aggressiveness </li></ul></ul><ul><li>TCP Reno problems </li></ul><ul><ul><li>Constantly updates window size </li></ul></ul><ul><ul><ul><li>Can lead to periodic oscillation in window size </li></ul></ul></ul><ul><ul><ul><li>Can lead to oscillation in round trip times, causing delay jitter and inefficient bandwidth utilization </li></ul></ul></ul><ul><ul><ul><li>Can have many retransmissions of the same packets after a packet is dropped </li></ul></ul></ul>
  23. 23. TCP Reno Pros and Cons (2) <ul><li>TCP Reno problems (continued) </li></ul><ul><ul><li>Connections with shorter round trip times can update congestion window sizes more quickly </li></ul></ul><ul><ul><ul><li>Such connections can received an unfair share of network capacity </li></ul></ul></ul><ul><ul><ul><li>TCP Reno is biased against connections with longer delays </li></ul></ul></ul>
  24. 24. TCP Vegas Pros and Cons <ul><li>TCP Vegas benefits </li></ul><ul><ul><li>Fair bandwidth estimation scheme </li></ul></ul><ul><ul><ul><li>Window update rate does not depend only on round-trip time as in TCP Reno </li></ul></ul></ul><ul><ul><li>Smooth sending rate and efficient link utilization when queue sizes are large (window stabilizes between  and  ) </li></ul></ul><ul><ul><li>TCP Vegas detects losses faster than TCP Reno and can recover from multiple drops more efficiently </li></ul></ul><ul><li>TCP Vegas problems </li></ul><ul><ul><li>Cannot compete with more aggressive TCP Reno connections </li></ul></ul><ul><ul><li>Vegas may not stabilize if buffers are small, leading to behavior that is similar to that of TCP Reno </li></ul></ul>
  25. 25. TCP Reno versus TCP Vegas <ul><li>TCP Vegas generally outperforms TCP Reno in a homogeneous environment </li></ul><ul><ul><li>TCP Vegas achieves between 40% and 70% better throughput </li></ul></ul><ul><ul><li>TCP Vegas has 20% to 50% of the losses compared to the TCP Reno </li></ul></ul><ul><li>Factors </li></ul><ul><ul><li>Slow-start and congestion avoidance have the greatest influence on throughput </li></ul></ul><ul><ul><li>Congestion detection mechanism during congestion avoidance has only minor or negative effect on throughput </li></ul></ul><ul><ul><li>Congestion detection mechanism may exhibit problems related to fairness among competing connections </li></ul></ul>
  26. 26. Agenda <ul><li>TCP overview </li></ul><ul><ul><li>Flow control </li></ul></ul><ul><ul><li>Congestion avoidance, slow start, and retransmission </li></ul></ul><ul><ul><li>TCP Reno and TCP Vegas </li></ul></ul><ul><li>TCP in wireless networks </li></ul><ul><li>Solutions to TCP performance problems in wireless networks </li></ul>
  27. 27. TCP Problems with Wireless <ul><li>Packet loss in wireless networks typically due to… </li></ul><ul><ul><li>Bit errors due to wireless channel impairments </li></ul></ul><ul><ul><li>Handoffs due to mobility </li></ul></ul><ul><ul><li>Possibly congestion, but not often </li></ul></ul><ul><li>As we’ve seen, TCP assumes packet loss is due to… </li></ul><ul><ul><li>Congestion in the network </li></ul></ul><ul><ul><li>Packet reordering, but not often </li></ul></ul><ul><li>In a wireless network, TCP congestion avoidance can be triggered by packet loss </li></ul><ul><ul><li>TCP’s mechanisms do not respond well to packet loss due to bit errors or handoffs </li></ul></ul><ul><ul><li>Performance of TCP-based applications can suffer </li></ul></ul>
  28. 28. More TCP Problems with Wireless <ul><li>Bursts of errors may occur due to low signal strength or longer period of noise </li></ul><ul><ul><li>More than one packet lost in TCP </li></ul></ul><ul><ul><li>More likely to be detected as a timeout  enter slow start! </li></ul></ul><ul><li>Delay is often very high </li></ul><ul><ul><li>Round-trip time can be very long and variable </li></ul></ul><ul><ul><li>TCP’s timeout mechanisms may not work well </li></ul></ul><ul><ul><li>Problem exacerbated by link-level retransmission </li></ul></ul><ul><li>Links may be asymmetric </li></ul><ul><ul><li>Delayed ACKs in the slow direction can limit throughput in the fast direction </li></ul></ul>
  29. 29. Week 13 In-Class Laboratory <ul><li>Experiments to consider… </li></ul><ul><ul><li>Influence of bit errors in the wireless channel on TCP performance </li></ul></ul><ul><ul><li>TCP Reno versus TCP Vegas in this environment </li></ul></ul><ul><li>Interactions are relatively complex </li></ul><ul><ul><li>Typical studies use simulation, which provides a very controlled environment </li></ul></ul><ul><ul><li>We’re being a bit bold in trying to do experimental measurements </li></ul></ul><ul><li>There is no at-home exercise for this week </li></ul><ul><ul><li>You will be responsible for findings and observations on the final exam </li></ul></ul>
  30. 30. Agenda <ul><li>TCP overview </li></ul><ul><ul><li>Flow control </li></ul></ul><ul><ul><li>Congestion avoidance, slow start, and retransmission </li></ul></ul><ul><ul><li>TCP Reno and TCP Vegas </li></ul></ul><ul><li>TCP in wireless networks </li></ul><ul><li>Solutions to TCP performance problems in wireless networks </li></ul>
  31. 31. General Solution Approaches <ul><li>Link-layer approaches </li></ul><ul><li>Split-connection approaches </li></ul><ul><li>End-to-end approaches </li></ul>
  32. 32. Link-Layer Protocols (1) <ul><li>Hide losses not due to congestion from the sender by making link appear to be more reliable </li></ul><ul><ul><li>Link-level automatic retransmission request (ARQ) </li></ul></ul><ul><ul><li>Forward error correction (FEC) codes </li></ul></ul><ul><ul><li>Hybrid ARQ and FEC </li></ul></ul><ul><li>Advantages </li></ul><ul><ul><li>Requires no change to existing sender behavior </li></ul></ul><ul><ul><li>Matches layered protocol model </li></ul></ul><ul><li>Problem </li></ul><ul><ul><li>Interactions with TCP, e.g., fast retransmission by TCP can be triggered by delays due to link-level timeout and retransmission </li></ul></ul>
  33. 33. Link-Layer Protocols (2) <ul><li>Negative interactions with TCP can be reduced by making the link-level protocol TCP-aware </li></ul><ul><ul><li>Example: Snoop TCP </li></ul></ul><ul><ul><li>Advantages </li></ul></ul><ul><ul><ul><li>Attempts to retransmit locally and suppress duplicate acknowledgements </li></ul></ul></ul><ul><ul><ul><li>State is soft, so handoff is simplified </li></ul></ul></ul><ul><ul><li>Disadvantage </li></ul></ul><ul><ul><ul><li>May not completely shield TCP from the effects of mobility and the wireless link </li></ul></ul></ul>
  34. 34. Split-Connection Protocols (1) <ul><li>Hide the wireless link entirely by terminating the TCP connection prior to the wireless link </li></ul><ul><ul><li>At the base station or access point </li></ul></ul><ul><li>Use a special protocol or regular TCP over the wireless link </li></ul><ul><li>Example: Indirect TCP </li></ul><ul><li>Problems </li></ul><ul><ul><li>Extra protocol overhead </li></ul></ul><ul><ul><li>Violates end-to-end semantics of TCP </li></ul></ul><ul><ul><li>Complicates handoff due to state information at the access point or base station where the protocol is “split” </li></ul></ul>
  35. 35. Split-Connection Protocols (2) TCP TCP* Logical TCP Connection Split Connection Host Host AP
  36. 36. End-to-End Protocols (1) <ul><li>Make TCP sender aware that some losses are not due to congestion and, thus, avoid congestion control when not needed </li></ul><ul><li>Use selective acknowledgement (SACKs) for “fine-grained” error recovery </li></ul><ul><ul><li>SACK RFC </li></ul></ul><ul><ul><li>SMART </li></ul></ul><ul><li>Use explicit loss notification (ELN) to distinguish between congestion and other losses </li></ul>
  37. 37. End-to-End Protocols (2) <ul><li>Advantages </li></ul><ul><ul><li>Maintains end-to-end semantics of TCP </li></ul></ul><ul><ul><li>Introduces no extra overhead at base stations for protocol processing or handoff </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Requires modified TCP </li></ul></ul><ul><ul><li>May not operate efficiently, e.g., for packet reordering versus packet loss </li></ul></ul>
  38. 38. Indirect TCP: Overview Wired Network Fixed Host Mobile Host TCP Proxy Standard TCP Standard TCP “ Wireless” TCP* Indirect TCP (* Normal TCP or modified transport protocol)
  39. 39. Indirect TCP: Handoff <ul><li>An access point or router can act as a Mobile IP foreign agent and as the TCP proxy for Indirect TCP (I-TCP) </li></ul><ul><li>If the mobile host moves to a different foreign agent, a handoff is needed for Mobile IP </li></ul><ul><li>If the mobile host moves to a different proxy, a handoff of the full TCP state is needed for I-TCP </li></ul><ul><ul><li>Buffered data </li></ul></ul><ul><ul><li>Sequence numbers </li></ul></ul><ul><ul><li>Port </li></ul></ul>
  40. 40. Indirect TCP: Advantages <ul><li>Does not require changes to TCP at the hosts in the fixed network </li></ul><ul><li>Errors from the wireless link are corrected at the TCP proxy and, thus, do not propagate through the fixed network </li></ul><ul><li>New protocol affects only a limited part of the Internet </li></ul><ul><li>Optimizations possible over wireless link </li></ul><ul><ul><li>Variance in delay between proxy and mobile host may be small, permitting optimized TCP </li></ul></ul><ul><ul><li>Opportunity for header compression, etc. </li></ul></ul><ul><ul><li>Opportunity for a different transport protocol </li></ul></ul>
  41. 41. Indirect TCP: Disadvantages <ul><li>Loss of TCP’s end-to-end semantics </li></ul><ul><ul><li>What happens if the proxy or the mobile host fails? </li></ul></ul><ul><li>Handoff overhead can be significant </li></ul><ul><li>Overhead at the proxy for per packet processing (up to TCP and back down) </li></ul><ul><ul><li>Can be reduced by good design </li></ul></ul><ul><li>TCP proxy must be trusted </li></ul><ul><ul><li>Obvious opportunities for snooping and denial of service </li></ul></ul><ul><ul><li>End-to-end IP-level privacy and authentication (e.g., using IPSec) must terminate at the proxy </li></ul></ul>
  42. 42. Indirect TCP: Wireless Transport <ul><li>I-TCP as originally proposed uses TCP as the wireless transport protocol </li></ul><ul><ul><li>Timeouts at the wireless sender may stall the original sender on the fixed network </li></ul></ul><ul><li>Selective acknowledgement protocols have been shown to provide better performance </li></ul><ul><ul><li>Better suited to wireless link with higher error rate </li></ul></ul>
  43. 43. Snoop TCP: Overview <ul><li>Provide reliable link layer that is TCP aware </li></ul><ul><ul><li>Snoop agent at the access point or foreign agent </li></ul></ul><ul><ul><li>Buffers data at the ends of the links for retransmissions (instead of going back to TCP end points) </li></ul></ul><ul><ul><li>“Snoops” on acknowledgements and filters duplicate acknowledgements </li></ul></ul>Wired Network Fixed Host Mobile Host Standard TCP Snoop Agent
  44. 44. Snoop TCP: Operation (1) <ul><li>Snoop agent monitors and buffers data sent from fixed network to mobile host </li></ul><ul><li>Snoop agent monitors ACKs from the mobile host </li></ul><ul><ul><li>Can discard buffer data when acknowledged </li></ul></ul><ul><ul><li>Can retransmit data when … </li></ul></ul><ul><ul><ul><li>Delayed ACK, or </li></ul></ul></ul><ul><ul><ul><li>Duplicate ACK </li></ul></ul></ul><ul><ul><li>Timeout can be relatively short leading to a fast retransmission </li></ul></ul><ul><li>Snoop Agent discards duplicate ACKs from mobile host </li></ul>
  45. 45. Snoop TCP: Operation (2) <ul><li>Snoop agent discards duplicate data that has already been sent by the agent and acknowledged </li></ul><ul><li>Snoop agent cannot generate ACKs that are sent back to the fixed host </li></ul><ul><ul><li>Unlike split-connection schemes, Snoop TCP preserves end-to-end TCP semantics </li></ul></ul>
  46. 46. Snoop TCP: Reverse Direction <ul><li>Snoop monitors traffic from mobile host back to fixed host and detects missing segments </li></ul><ul><li>A negative ACK (NACK) is sent immediately to the mobile host </li></ul><ul><li>Mobile host can retransmit missing segment, hopefully in time to avoid a TCP timeout at the fixed host </li></ul>
  47. 47. Snoop TCP: Advantages <ul><li>Preserves end-to-end TCP semantics </li></ul><ul><li>Requires no changes in TCP for fixed hosts </li></ul><ul><li>No changes in TCP are possible for the mobile hosts, but reverse direction traffic can benefit from changes at mobile host </li></ul><ul><li>There is no need for handoff </li></ul><ul><li>Automatic fallback to standard TCP </li></ul><ul><ul><li>No need to ensure that all foreign networks provide a Snoop agent </li></ul></ul>
  48. 48. Snoop TCP: Disadvantages <ul><li>Does not fully isolate wireless link errors from the fixed network </li></ul><ul><li>Mobile host must be modified to handle NACKs for reverse (mobile to fixed) traffic </li></ul><ul><li>Cannot snoop encrypted datagrams </li></ul><ul><ul><li>Cannot use with privacy </li></ul></ul><ul><li>Retransmission of data from agent not authenticated due to protection from replay attacks </li></ul><ul><ul><li>Cannot use with authentication </li></ul></ul>
  49. 49. Summary <ul><li>TCP is a complex protocol </li></ul><ul><ul><li>Minimal support from underlying protocols </li></ul></ul><ul><ul><li>Indirect observation of network environment </li></ul></ul><ul><ul><li>Large number of competing flows from different hosts </li></ul></ul><ul><ul><li>Congestion avoidance is still a research issue </li></ul></ul><ul><li>TCP does not perform well in a wireless environment where packets are usually lost due to bit errors, not congestion </li></ul><ul><li>Schemes have been proposed to address TCP performance problems </li></ul><ul><ul><li>Link-level recovery </li></ul></ul><ul><ul><li>Split protocols </li></ul></ul><ul><ul><li>End-to-end protocols </li></ul></ul>