Overview of Transport Problems in WLANs. Packet loss in wireless networks may be due to Bit errors Handoffs Congestion (rarely) Reordering (rarely, except for certain types of wireless nets) TCP assumes packet loss is due to Congestion Reordering (rarely) - PowerPoint PPT Presentation
50
TRANSPORT PROTOCOLS FOR TRANSPORT PROTOCOLS FOR WLANs and AD HOC NETWORKS WLANs and AD HOC NETWORKS Ian F. Akyildiz Ian F. Akyildiz Broadband & Wireless Networking Laboratory Broadband & Wireless Networking Laboratory School of Electrical and Computer Engineering School of Electrical and Computer Engineering Georgia Institute of Technology Georgia Institute of Technology Tel: 404-894-5141; Fax: 404-894-7883 Tel: 404-894-5141; Fax: 404-894-7883 Email: [email protected]Email: [email protected]Web: http://www.ece.gatech.edu/research/labs/bwn Web: http://www.ece.gatech.edu/research/labs/bwn
Transcript
TRANSPORT PROTOCOLS FORTRANSPORT PROTOCOLS FORWLANs and AD HOC NETWORKSWLANs and AD HOC NETWORKS
Overview of Overview of Transport Problems Transport Problems in WLANsin WLANs
Packet loss in wireless networks may be due toPacket loss in wireless networks may be due to– Bit errors Bit errors – HandoffsHandoffs– Congestion (rarely)Congestion (rarely)– Reordering (rarely, except for certain types Reordering (rarely, except for certain types
of wireless nets)of wireless nets) TCP assumes packet loss is due toTCP assumes packet loss is due to
TCP’s congestion responses are triggered by TCP’s congestion responses are triggered by wireless packet loss but interact poorly with wireless packet loss but interact poorly with wireless netswireless nets
3IFA’2004
TCP Congestion TCP Congestion DetectionDetection
TCP assumes timeouts and duplicate acks TCP assumes timeouts and duplicate acks indicate congestion or (rarely) packet indicate congestion or (rarely) packet reorderingreordering
Timeout indicates packet or ACK was lostTimeout indicates packet or ACK was lost Duplicate ACKs may indicate packet Duplicate ACKs may indicate packet
reorderingreordering– ACKs up through last successful in-order ACKs up through last successful in-order
packet receivedpacket received– Called a “cumulative” ACKCalled a “cumulative” ACK– After three duplicate ACKs, assume packet After three duplicate ACKs, assume packet
loss, not reorderingloss, not reordering– Receipt of duplicate ACKs means some data is Receipt of duplicate ACKs means some data is
still flowingstill flowing
4IFA’2004
TCP Congestion TCP Congestion ControlControl
Basic timeout and retransmissionBasic timeout and retransmission– If sender receives no ACK for data sent, timeout If sender receives no ACK for data sent, timeout
and retransmitand retransmit– Go To Slow Start (Exponential back-off)Go To Slow Start (Exponential back-off)– Timeout value based on mean and variance of RTTTimeout value based on mean and variance of RTT
Congestion “avoidance” (really congestion control)Congestion “avoidance” (really congestion control)– Uses congestion window (Uses congestion window (cwndcwnd) for more flow ) for more flow
controlcontrol– CwndCwnd set to set to 1/21/2 of its value when congestion loss of its value when congestion loss
occurredoccurred– Sender can send up to minimum of advertised Sender can send up to minimum of advertised
window and window and cwndcwnd– Then, additive increase Then, additive increase cwndcwnd (at most (at most 11 at each at each
RTTRTT))– Careful way to approach limit of networkCareful way to approach limit of network
5IFA’2004
TCP Congestion TCP Congestion Control (cont’d)Control (cont’d)
Slow start – used to initiate a connection or after a timeoutSlow start – used to initiate a connection or after a timeout– Set Set cwndcwnd to to 11 segment segment– At each At each ACKACK, increase , increase cwndcwnd by by 11 segment (exponential segment (exponential
increase)increase)– Aggressive way of building up bandwidth for flowAggressive way of building up bandwidth for flow– Switch to congestion avoidance once Switch to congestion avoidance once cwndcwnd is one half is one half
of what it was when congestion occurredof what it was when congestion occurred Fast retransmit and fast recoveryFast retransmit and fast recovery
– After three duplicate After three duplicate ACKACKs, assume packet loss, data s, assume packet loss, data still flowingstill flowing
– Sender resends missing segmentSender resends missing segment– Set Set cwndcwnd to to ½½ of current of current cwndcwnd plus plus 33 segments segments– For each duplicate For each duplicate ACKACK, increment , increment cwndcwnd by by 11 (keep flow (keep flow
going)going)– When new data acked, do regular congestion avoidanceWhen new data acked, do regular congestion avoidance
6IFA’2004
Poor Interaction with Poor Interaction with TCPTCP
Packet loss due to channel noise or mobilityPacket loss due to channel noise or mobility– Enter congestion controlEnter congestion control– Slow increase of Slow increase of cwndcwnd
Bursts of packet loss and hand-offsBursts of packet loss and hand-offs– TimeoutTimeout– Enter slow start (very painful!)Enter slow start (very painful!)
Cumulative Cumulative ACKACK scheme not good with bursty losses scheme not good with bursty losses– Missing data detected one segment at a timeMissing data detected one segment at a time– Duplicate Duplicate ACKACKs take a while to cause retransmissions take a while to cause retransmission– TCP Reno may suffer coarse time-out and enter slow TCP Reno may suffer coarse time-out and enter slow
start!start!– TCP New Reno still only retransmits one packet per TCP New Reno still only retransmits one packet per
RTTRTT
7IFA’2004
Solution CategoriesSolution Categories Entirely new transport protocolEntirely new transport protocol
– Hard to deploy widelyHard to deploy widely– End-to-end protocol needs to be efficient on End-to-end protocol needs to be efficient on
wired networks toowired networks too– Must implement much of TCP’s flow controlMust implement much of TCP’s flow control
Modifications to TCPModifications to TCP– Maintain end-to-end semanticsMaintain end-to-end semantics– May or may not be backwards compatibleMay or may not be backwards compatible
Split-connection TCPSplit-connection TCP– Breaks end-to-end nature of protocolBreaks end-to-end nature of protocol– May be backwards compatible with end-hostsMay be backwards compatible with end-hosts– State on basestation may make handoffs slowState on basestation may make handoffs slow– Extra TCP processing at basestationExtra TCP processing at basestation
Link-layer protocolsLink-layer protocols– Invisible to higher-level protocolsInvisible to higher-level protocols– Does not break higher-level end-to-end Does not break higher-level end-to-end
semanticssemantics– May not shield sender completely from packet May not shield sender completely from packet
lossloss– May adversely interact with higher-level May adversely interact with higher-level
mechanismsmechanisms– May adversely affect delay-sensitive May adversely affect delay-sensitive
– Does not break end-to-end semanticsDoes not break end-to-end semantics– Like a LL protocol, does not completely shield Like a LL protocol, does not completely shield
sendersender– Only soft state at base station – not essential Only soft state at base station – not essential
Sender is aware of the existence of wireless Sender is aware of the existence of wireless hops.hops.
E2E (Reno): no support for partial ACKsE2E (Reno): no support for partial ACKs E2E-NewReno: partial ACKs allow further packet E2E-NewReno: partial ACKs allow further packet
describes 3 received non-contiguous rangesdescribes 3 received non-contiguous ranges E2E-SMART: cumulative ACK with sequence # of E2E-SMART: cumulative ACK with sequence # of
packet causing ACKpacket causing ACK– Sender uses info for bitmask of okay packetsSender uses info for bitmask of okay packets– Ignores possibility that holes are due to Ignores possibility that holes are due to
reorderingreordering– Easier to generate and transmit acksEasier to generate and transmit acks
10IFA’2004
E2E-ELN: Explicit Loss E2E-ELN: Explicit Loss NotificationNotification– Receiver gets corrupted packetReceiver gets corrupted packet– Instead of dropping it, TCP gets Instead of dropping it, TCP gets
it, generates ELN message with it, generates ELN message with duplicate ACKduplicate ACK
– Entire packet dropped?Entire packet dropped?Base station generates ELN messages Base station generates ELN messages
to sender with ACK streamto sender with ACK stream
Performance Performance Results of E2E Results of E2E ProtocolsProtocols
E2E (Reno): coarse-grained timeouts really hurtE2E (Reno): coarse-grained timeouts really hurt– Throughput less than 50% of maximum in local areaThroughput less than 50% of maximum in local area– Throughput of less than 25% in wide areaThroughput of less than 25% in wide area
E2E-New Reno: avoiding timeouts helpsE2E-New Reno: avoiding timeouts helps– Throughput 10-25% better in LANThroughput 10-25% better in LAN– Throughput twice as good in WANThroughput twice as good in WAN
ELN techniques avoid shrinking congestion windowELN techniques avoid shrinking congestion window– Over two times better than E2EOver two times better than E2E
E2E-ELN-RXMT (ELN+Fast Retransmissions) only a little E2E-ELN-RXMT (ELN+Fast Retransmissions) only a little better than E2E-ELNbetter than E2E-ELN– Enough data in pipe usually to get fast retransmit Enough data in pipe usually to get fast retransmit
from ELNfrom ELN– Bigger difference with smaller buffer sizeBigger difference with smaller buffer size
Not as much data in pipe (harder to get 3 duplicate acks)Not as much data in pipe (harder to get 3 duplicate acks)
12IFA’2004
E2E selective acks (SACK):E2E selective acks (SACK):– Over twice as good as E2EOver twice as good as E2E– Not as good as best LL Not as good as best LL
schemes (10% worse on LAN, schemes (10% worse on LAN, 35% worse in WAN)35% worse in WAN)
– Problem is still shrinkage of Problem is still shrinkage of congestion windowcongestion window
Performance Performance Results of E2E Results of E2E Protocols (Cont’d)Protocols (Cont’d)
Goal:Goal: to hide any non-congestion-related to hide any non-congestion-related losses from the TCP sender.losses from the TCP sender.
Attempt to isolate TCP source from wireless Attempt to isolate TCP source from wireless losseslosses
TCP connection is split between a sender TCP connection is split between a sender and receiver into two separate connections and receiver into two separate connections at the base station:at the base station:– TCP connection over wired link;TCP connection over wired link;– Specialized protocol over wireless link.Specialized protocol over wireless link.
TCP sender over wireless link performs all TCP sender over wireless link performs all retransmissions in response to lossesretransmissions in response to losses– SPLIT (I-TCP): uses TCP Reno over wireless linkSPLIT (I-TCP): uses TCP Reno over wireless link– SPLIT-SMART: uses SMART-based selective acksSPLIT-SMART: uses SMART-based selective acks
Connection between wireless Connection between wireless host MH and fixed host FH host MH and fixed host FH goes through base station BSgoes through base station BS
Split connection results in Split connection results in independent flow control for the independent flow control for the two partstwo parts
Flow/error control protocols, Flow/error control protocols, packet size, time-outs, may be packet size, time-outs, may be different for each partdifferent for each part
FH MHBS
Base Station Mobile HostFixed Host
16IFA’2004
I-TCP: Indirect TCPI-TCP: Indirect TCP
MH
MSR
FH
• MH = Mobile Host• MSR = Mobile Support Router• FH = Fixed Host
I-TCP TCP
17IFA’2004
Indirect-TCP Indirect-TCP ProtocolProtocol
Different flow control and congestion Different flow control and congestion control for wireless and wired links;control for wireless and wired links;
Separate transport protocol supports Separate transport protocol supports disconnections, moves and other disconnections, moves and other wireless related features;wireless related features;
Faster reaction to mobility due to Faster reaction to mobility due to proximity between MSR and MH.proximity between MSR and MH.
MSR manages much of the overheadMSR manages much of the overhead
18IFA’2004
I-TCP BasicsI-TCP Basics
move
MSR-2
FH
MH
MH socket
MH
MH socket
MSR-1 MSR-1
MSR1mhsocket
MSR1fhsocket
MSR2fhsocket
MSR2mhsocket
FH socket
I-TCP Handoff
Regular TCP
Wireless TCP
19IFA’2004
I-TCPI-TCP
Built on top of a mobile IP Built on top of a mobile IP MSR acts a proxy to the MH MSR acts a proxy to the MH
– it fakes an image of the MH and hands it fakes an image of the MH and hands this to a new MSR during cell switchesthis to a new MSR during cell switches
Assuming no MSR failures and Assuming no MSR failures and indefinite MH disconnection, I-TCP indefinite MH disconnection, I-TCP does not compromise end-to-end does not compromise end-to-end reliability.reliability.
Well-suited for throughput intensive Well-suited for throughput intensive applicationsapplications
Advantages:Advantages: Simple ImplementationSimple Implementation Backward compatible to TCP fixed hostsBackward compatible to TCP fixed hosts
– FH unaware of MSRsFH unaware of MSRs Separates flow and congestion control of Separates flow and congestion control of
the wireless and wired linkthe wireless and wired link Can optimize FH-MSR connection Can optimize FH-MSR connection
independently - different protocols, MTUsindependently - different protocols, MTUs Can support notifications that can be used Can support notifications that can be used
by link and location aware applicationsby link and location aware applications
Disadvantages:Disadvantages: Violation of end-to-end semanticsViolation of end-to-end semantics MSR maintains state MSR maintains state MSR failure can cause connection MSR failure can cause connection
lossloss Hand-off latency increases due to Hand-off latency increases due to
state transferstate transfer Unless optimized, extra copying of Unless optimized, extra copying of
data at MSR data at MSR
22IFA’2004
Performance of Performance of Split ApproachesSplit Approaches
SPLIT:SPLIT:– Wired goodput 100% since no retransmissions Wired goodput 100% since no retransmissions
therethere– Eventually stalls when wireless link times outEventually stalls when wireless link times out– Buffer space limited at base stationBuffer space limited at base station
SPLIT-SMART:SPLIT-SMART:– Throughput better than SPLIT (at least twice Throughput better than SPLIT (at least twice
as good)as good)– Better performance of wireless link avoids Better performance of wireless link avoids
holding up wired links as muchholding up wired links as much Split connections not as effective as TCP-Split connections not as effective as TCP-
aware LL protocol, which also avoids splitting aware LL protocol, which also avoids splitting the connectionthe connection
23IFA’2004
Link Layer Link Layer ApproachesApproaches
LL: TCP-like behavior with cumulative acks LL: TCP-like behavior with cumulative acks and retransmit granularity faster than TCP’sand retransmit granularity faster than TCP’s
LL-SMART: addition of selective LL-SMART: addition of selective retransmissionsretransmissions– Cumulative ack with sequence # of of packet Cumulative ack with sequence # of of packet
– At base station cache segmentsAt base station cache segments– Detect and suppress duplicate acksDetect and suppress duplicate acks– Retransmit lost segments locallyRetransmit lost segments locally
LL-SMART-TCP-AWARE: Combination of LL-SMART-TCP-AWARE: Combination of selective acks and duplicate ack suppressionselective acks and duplicate ack suppression
24IFA’2004
Snoop ProtocolSnoop Protocol
Design Goals:Design Goals: Improved PerformanceImproved PerformanceNo change to TCP at fixed hostsNo change to TCP at fixed hostsNo violation of end-to-end TCP No violation of end-to-end TCP
semanticssemanticsNo recompiling/relinking of No recompiling/relinking of
existing applicationsexisting applications
25IFA’2004
Snoop ProtocolSnoop Protocol
Buffers dataBuffers data packets at the base packets at the base station BSstation BS– to allow link layer retransmissionto allow link layer retransmission
When dupacks received by BS from When dupacks received by BS from MH, MH, retransmit retransmit on wireless link, if on wireless link, if packet present in bufferpacket present in buffer
Prevents fast retransmitPrevents fast retransmit at TCP at TCP sender FH by dropping the dupacks sender FH by dropping the dupacks at BSat BS
FH MHBS
26IFA’2004
Snoop ProtocolSnoop Protocol
FH MHBSwireless
physical
link
network
transport
application
physical
link
network
transport
application
physical
link
network
transport
application
rxmt
Per TCP-connection state
TCP connection
27IFA’2004
Snoop Protocol Snoop Protocol
Advantages:Advantages: High throughput can be achievedHigh throughput can be achieved
– performance further improved using performance further improved using selective acksselective acks
Local recovery from wireless lossesLocal recovery from wireless losses Fast retransmit not triggered at sender Fast retransmit not triggered at sender
despite out-of-order link layer deliverydespite out-of-order link layer delivery End-to-end semantics retainedEnd-to-end semantics retained Soft state at base stationSoft state at base station
– loss of the soft state affects loss of the soft state affects performance, but not correctnessperformance, but not correctness
28IFA’2004
Snoop ProtocolSnoop Protocol
Disadvantages:Disadvantages: Link layer at base station needs to Link layer at base station needs to
be be TCP-awareTCP-aware Not useful if TCP headers are Not useful if TCP headers are
encrypted (IPsec)encrypted (IPsec) Cannot be used if TCP data and TCP Cannot be used if TCP data and TCP
acks traverse different paths (both acks traverse different paths (both do not go through the base station)do not go through the base station)
29IFA’2004
Link Layer Link Layer Approaches Approaches ResultsResults
Simple retransmission at link layer Simple retransmission at link layer helps, but not totallyhelps, but not totally
Combination of selective acks and Combination of selective acks and duplicate suppression is bestduplicate suppression is best
Real problem is link layers that allow Real problem is link layers that allow out-of-order packet delivery, out-of-order packet delivery, triggering duplicate acks, fast triggering duplicate acks, fast retransmission and congestion retransmission and congestion avoidance in TCPavoidance in TCP
Overall, want to avoid triggering TCP Overall, want to avoid triggering TCP congestion handling techniquescongestion handling techniques
30IFA’2004
SummarySummary
Good TCP-aware LL shields sender from duplicate acksGood TCP-aware LL shields sender from duplicate acks– Avoids redundant retransmissions by sender and Avoids redundant retransmissions by sender and
base stationbase station– Adding selective acks helps a lot with bursty errorsAdding selective acks helps a lot with bursty errors
Split connection with standard TCP shields sender from Split connection with standard TCP shields sender from losses, but poor wireless link still causes sender to stalllosses, but poor wireless link still causes sender to stall– Adding selective acks over wireless link helps a lotAdding selective acks over wireless link helps a lot– Still not as good as local LL improvementStill not as good as local LL improvement
E2E schemes with selective acks help a lotE2E schemes with selective acks help a lot– Still not as good as best LL schemesStill not as good as best LL schemes
Explicit loss E2E schemes help (avoid shrinking Explicit loss E2E schemes help (avoid shrinking congestion window) but should be combined with SACK congestion window) but should be combined with SACK for multiple packet lossesfor multiple packet losses
31IFA’2004
SummarySummary
TCP-aware link-layer protocol (Snoop) with selective acknowledgments performs TCP-aware link-layer protocol (Snoop) with selective acknowledgments performs the best;the best;
Split-connection approaches is not a requirement for good performance.Split-connection approaches is not a requirement for good performance. Selective acknowledgment is very useful in lossy links, especially for burst losses.Selective acknowledgment is very useful in lossy links, especially for burst losses. Explicit Loss Notification is worth to try.Explicit Loss Notification is worth to try.
32IFA’2004
Effect of route reconstruction/repairEffect of route reconstruction/repair Effect of network partitioning/merging, multi-Effect of network partitioning/merging, multi-
path routingpath routing– Sender mistakes the delay of ACK arrival and Sender mistakes the delay of ACK arrival and
increases RTT as a sign of congestionincreases RTT as a sign of congestion– Sender begins to reduce window sizeSender begins to reduce window size
High bit error ratesHigh bit error rates– problem amplified with multiple hopsproblem amplified with multiple hops
Out-of-order packet deliveryOut-of-order packet delivery– frequent route changes may cause out-of-order frequent route changes may cause out-of-order
mobility causeslink breakage,resulting in routefailure
TCP data and acksen route discarded
Throughput Throughput Degradation with Route Degradation with Route FailureFailure
TCP sender times out.Starts sending packets again
Route isrepaired
No throughput
No throughputdespite route repair
36IFA’2004
mobility causeslink breakage,resulting in routefailure
TCP data and acksen route discarded
TCP sendertimes out.Backs off timer.
Route isrepaired
TCP sendertimes out.Resumessending
Larger route repair delaysespecially harmful
No throughput
No throughput
despite route repair
Throughput Throughput Degradation with Route Degradation with Route FailureFailure
37IFA’2004
Caching and TCP Caching and TCP PerformancePerformance
Caching can reduce overhead of Caching can reduce overhead of route discovery even if cache route discovery even if cache accuracy is not very highaccuracy is not very high
But if cache accuracy is not high But if cache accuracy is not high enough, gains in routing overhead enough, gains in routing overhead may be offset by loss of TCP may be offset by loss of TCP performance due to multiple time-performance due to multiple time-outsouts
38IFA’2004
Impact of MAC - Impact of MAC - Delay VariabilityDelay Variability
As wireless medium is shared between As wireless medium is shared between multiple sources, the round-trip delay is multiple sources, the round-trip delay is variablevariable
Also, on slow wireless networks, delay is largeAlso, on slow wireless networks, delay is large– made larger by send-receive turnaround timemade larger by send-receive turnaround time
Large and variable delays result in larger RTOLarge and variable delays result in larger RTO On packet loss, timeout takes much longer to On packet loss, timeout takes much longer to
occuroccur Idle source (waiting for timeout to occur) Idle source (waiting for timeout to occur)
Maintains TCP congestion control Maintains TCP congestion control behaviourbehaviour
Is compatible with TCP standardIs compatible with TCP standard
43IFA’2004
Design of ATCPDesign of ATCP
Transparent layer between standard TCP and IP.Transparent layer between standard TCP and IP.– Standard TCP is unmodified.Standard TCP is unmodified.– Nodes with and without ATCP can interoperate.Nodes with and without ATCP can interoperate.– Only used on sender-side.Only used on sender-side.
Monitors TCP and Network state based on Explicit Monitors TCP and Network state based on Explicit Congestion Notification (ECN) and Internet Control Congestion Notification (ECN) and Internet Control Management Protocol (ICMP) messagesManagement Protocol (ICMP) messages
TCP
TCP
ATCP
IP
44IFA’2004
ATCP State ATCP State Transition DiagramTransition Diagram
45IFA’2004
Loss StateLoss State Normal Normal Loss state transition occurs Loss state transition occurs
when packet loss due to high BER when packet loss due to high BER channel implied:channel implied:– ATCP sees that TCP’s RTO is about to expire ATCP sees that TCP’s RTO is about to expire OROR– ATCP receives 3 duplicate acknowledgements.ATCP receives 3 duplicate acknowledgements.
ATCP retransmits lost packet(s) instead ATCP retransmits lost packet(s) instead of TCP.of TCP.
When new acknowledgement arrives,When new acknowledgement arrives,– ATCP passes it to TCPATCP passes it to TCP– TCP exits persist modeTCP exits persist mode– State transition from Loss State transition from Loss Normal Normal
46IFA’2004
Congested StateCongested State Normal Normal Congested state transition occurs Congested state transition occurs
when sender receives TCP acknowledgement when sender receives TCP acknowledgement with with explicit congestion notificationexplicit congestion notification (ECN) bit (ECN) bit set.set.– ECN bit set in TCP acknowledgement when ECN bit set in TCP acknowledgement when
router detects congestion (instead of dropping router detects congestion (instead of dropping the packet).the packet).
ATCP does nothing in congested state:ATCP does nothing in congested state:– Ignore imminent RTO andIgnore imminent RTO and– Ignore duplicate acknowledgementsIgnore duplicate acknowledgements
TCP would behave as normalTCP would behave as normal When TCP transmits a new packet, ATCP When TCP transmits a new packet, ATCP
transitions from Congested transitions from Congested Normal. Normal.
47IFA’2004
Disconnected StateDisconnected State
Normal Normal Disconnected state transition Disconnected state transition occurs when ICMP occurs when ICMP Destination Destination UnreachableUnreachable packet received. packet received.– ICMP Destination Unreachable packet ICMP Destination Unreachable packet
generated by network in response to a generated by network in response to a packet being sent to an unreachable packet being sent to an unreachable node.node.
TCP continuously transmits probe TCP continuously transmits probe packets.packets.– When acknowledgement to probe packet When acknowledgement to probe packet
is received, this means destination node is received, this means destination node is no longer disconnected.is no longer disconnected.
48IFA’2004
SummarySummary
Much work on Much work on routingrouting in ad hoc in ad hoc networksnetworks
Some recent work on TCP for ad Some recent work on TCP for ad hoc networkshoc networks
Need to investigate many issues Need to investigate many issues – MAC-TCP interactionMAC-TCP interaction– routing-TCP interactionrouting-TCP interaction– impact of route changes on window impact of route changes on window
size, RTO choice after movesize, RTO choice after move
49IFA’2004
ReferencesReferences[1] Hari Balakrishnan, Srinivasan Seshan and Randy [1] Hari Balakrishnan, Srinivasan Seshan and Randy
H.Katz, H.Katz, “Improving Reliable Transport and Handoff “Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks”Performance in Cellular Wireless Networks”, ACM , ACM Wireless Networks, May 1995Wireless Networks, May 1995
[2] Hari Balakrishnan, Venkata N. Padmanabhan, [2] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan and Randy H.Katz, Srinivasan Seshan and Randy H.Katz, “A Comparison “A Comparison of Mechanisms for Improving TCP Performance over of Mechanisms for Improving TCP Performance over Wireless Links”Wireless Links”, ACM SIGCOMM 1996., ACM SIGCOMM 1996.
[3] A.Bakre and B.R.Badrinath, [3] A.Bakre and B.R.Badrinath, “I-TCP: Indirect TCP for “I-TCP: Indirect TCP for Mobile Hosts”Mobile Hosts”,Proc. 15,Proc. 15thth Int’l Conf. on Distributed Int’l Conf. on Distributed Computing Systems, May 1995Computing Systems, May 1995
[4] A.Bakre and B.R.Badrinath, [4] A.Bakre and B.R.Badrinath, “Implementation and “Implementation and Performance Evaluation of Indirect TCP”Performance Evaluation of Indirect TCP”, IEEE , IEEE Transactions on Computers, March 1997Transactions on Computers, March 1997
[5] RFC 2001 – [5] RFC 2001 – TCP Slow Start, Congestion Avoidance, Fast TCP Slow Start, Congestion Avoidance, Fast Retransmit and Fast RecoveryRetransmit and Fast Recovery
50IFA’2004
ReferencesReferences[6] J. Liu and S. Singh, "[6] J. Liu and S. Singh, "ATCP: TCP for mobile ad hoc ATCP: TCP for mobile ad hoc
networksnetworks,“ IEEE JSAC, vol. 19, no. 7, pp. 1300-,“ IEEE JSAC, vol. 19, no. 7, pp. 1300-1315, July 2001.1315, July 2001.
[7] K. Sundaresan, V. Anantharaman, H.-Y. Hsieh, [7] K. Sundaresan, V. Anantharaman, H.-Y. Hsieh, and R. Sivakumar, “and R. Sivakumar, “ATP: A Reliable Transport ATP: A Reliable Transport Protocol for Ad-hoc Networks."Protocol for Ad-hoc Networks." Proc. ACM Proc. ACM MOBIHOC 2003, Annapolis, MD USA, June 2003. MOBIHOC 2003, Annapolis, MD USA, June 2003.
