Post on 14-Feb-2016
description
Postech Postech DP&NM LabDP&NM Lab
Freeze-TCP: a true end-to-end TCP enhancement mechanism for mobile envi
ronments
Goff, T.; Moronski, J.; Phatak, D.S.; Gupta, V. INFOCOM 2000
Lee Hyo Jin2001 Fall Mobile Networks 발표자료
Nov/28/2001 Prof. Young-Joo Suh
Freeze-TCP (2) Postech Postech DP&NM LabDP&NM Lab
Reference• Tom Goff et el, "Freeze-TCP: A True End-to-End TCP Enh
ancement Mechanism for Mobile Environments," INFOCOM'00.
• K. Brown and S. Singh, “M-TCP: TCP for Mobile Cellular Networks,” ACM Computer Communications Review (CCR), vol. 27, no. 5, 1997.
• Ajay Bakre and B.R. Badrinath, “I-TCP: Indirect TCP for mobile hosts,” Tech. Rep., Rutgers University, May 1995,
Freeze-TCP (3) Postech Postech DP&NM LabDP&NM Lab
Contents• Introduction.• Requirement• Key concepts.• TCP window management.• Introduce to existing solutions.• Details of Freeze-TCP.• Experimental result.• Conclusion and Discussion.
Freeze-TCP (4) Postech Postech DP&NM LabDP&NM Lab
Introduction • Need to optimize TCP for mobility.• Not true end-to-end scheme.
– Intermediaries. ( like Base Stations )• To monitor the TCP traffic and participate in flow control to
enhance TCP performance.
– Not applicable when IP payload is encrypted.(IPSEC)• Security associations between sender and receiver.
• Require changes TCP/IP code at intermediate node.– It is difficult for mobile clients to inter-operate with the
existing infrastructure.
Freeze-TCP (5) Postech Postech DP&NM LabDP&NM Lab
Requirements
• True end to end scheme.• Interoperate existing infrastructure.
– TCP code must change in mobile client (MH)• Need to performance enhancement.
We need a new scheme.
Freeze-TCP (6) Postech Postech DP&NM LabDP&NM Lab
Key Concepts
• No help with base stations in hand-off.• To detect an impending handoff at client.( MH )• ZWA(MH): zero window advertisement.• ZWP (FH) : zero window probes.• TR-ACKs : Triplicate acks.• True end to end semantics.• Performance enhancement.
Freeze-TCP (7) Postech Postech DP&NM LabDP&NM Lab
TCP window management -1• The window size
– minimum of receiver’s advertised buffer size – perceived network congestions.
• The receiver run out of its buffer-space and advertise a window size of zero. ( ZWA )
• The sender should freeze all retransmit-timers and enter a persist-mode on seeing ZWA.
Freeze-TCP (8) Postech Postech DP&NM LabDP&NM Lab
TCP window management -2
Ack1 win4
12
43 4 5 6
8
DATA3 ~ 6 win4
Data1 win4
Ack6 win0Ack6 win4
9
10 11 12 13
DATA10 ~13 win4 ZW
A
sender
receiver
Freeze-TCP (9) Postech Postech DP&NM LabDP&NM Lab
TCP window management -3• ZWP• Sending probes until the receiver’s window opens up.• Sender want to knows receiver’s window opened or not, in
advance. • Interval
– exponential back-off until it reaches 1 minute– remains constant after 1 minute.
• Receiver responds to a ZWP with a non-zero window size.• Sender will continue transmission using a window size
consistent with the advertised value.
Freeze-TCP (10) Postech Postech DP&NM LabDP&NM Lab
TCP window management -6
Ack1 win4
12
43 4 5 6
8
DATA3 ~ 6 win4
Data1 win4
Ack6 win0Ack6 win4
9
10 11 12 13
DATA10 ~13 win4 ZW
A
ZWP
Freeze-TCP (11) Postech Postech DP&NM LabDP&NM Lab
TCP window management -7
8Ack6 win0
9
10 11 12 13 DATA10 ~13
win4
ZWP
Probe response (win4)
Original ack
Freeze-TCP (12) Postech Postech DP&NM LabDP&NM Lab
Existing Solutions• SNOOP • I-TCP ( Indirect TCP )• EBSN ( Explicit bad state notifications )• Delayed dupacks• M-TCP
Freeze-TCP (13) Postech Postech DP&NM LabDP&NM Lab
I-TCP• Split the connection
– FH-BS : Standard TCP.– BS-MH : Standard TCP ,Optimi
zing protocol.(MTCP)
• Retain a little RTT – Fast recovery about cwnd size d
egradations.
• Need to exchange the status information – Long delay time.– MSR buffer size is small. (to re
duce handoff time)– MSR : Mobility Support Router
s.
MH
FH
MH
MH socket(mhaddr, mhport, msr1addr, msr1port)
MSR1or 2 mhsocket(msr1addr, msr1port, mhaddr, mhport)
MSR 1 MSR 2
MSR1or 2 fhsocket(mhaddr, mhport, fhaddr, fhport)
FH socket(fhaddr, fhport, mhaddr, mhport)
Regular TCP
Wireless TCP
Freeze-TCP (14) Postech Postech DP&NM LabDP&NM Lab
EBSN• Explicit bad-state notifications.• BS sends an EBSN to sender when each failed
attempt to send a packet to a MH.• On receipt of each EBSN, the sender reset
retransmission timer to original value.• Prevent the sender from dropping congestion
window.
Freeze-TCP (15) Postech Postech DP&NM LabDP&NM Lab
M-TCP (1)• Performance enhancement
during hand-off.• Low BER and Frequent
disconnections.• 3 level hierarchy structure.
– Reduce MSS functions– No need to exchange the
status info moving MSS in the same SH domain.
High-speed Network
SH SH
MH
MSS
Cell
SH : Supervisor Host
MSS : Mobile Support Station
MH : Mbile Host
Freeze-TCP (16) Postech Postech DP&NM LabDP&NM Lab
M-TCP (2)• End to end TCP semantics.
– TCP connection is split at the BS– The SH does not send an ack FH unless BS has receive
d an ack from MH.
FH
MH
BS
Freeze-TCP (17) Postech Postech DP&NM LabDP&NM Lab
M-TCP (3)• TCP Persist Mode
– When the positive window advertisement is received, sender exits persist mode.
– Retain RTO and congestion window size.• Need help from BS.
– BS detect disconnection or packet loss.– BS withholds ack for last one byte.– Re-packetization penalty at sender.– This ack uses to send to zero window advertisement at
hand off.
Freeze-TCP (18) Postech Postech DP&NM LabDP&NM Lab
TPC Performanceenhancement degradation
M-TCP Good Re-packetization overhead at sender
SNOOPI-TCP( MTCP )
Handle Bit-error
Frequent hand-off or disconnections
Delayed dupacks
Single packet losses
Actual congestion losses
EBSN Significant duration or burst error
Random error
Freeze-TCP (19) Postech Postech DP&NM LabDP&NM Lab
Picture of Freeze-TCP
Fixed Host
(Sender)
ZWA
ZWP
BS
BS
MH
MH MHMH
Connection
Probe res
Freeze-TCP (20) Postech Postech DP&NM LabDP&NM Lab
ZWPFreeze-TCP (2)
• ZWP – ZWA force the sender into the ZWP (persist) mode.– To prevent it from dropping its congestion window.– To send ZWPs until the receiver’s opens up– The interval grows exponentially (exponential back of
f ) until it reaches 1 minute.– ZWP reponse does not have receiver’s advertisement w
indow size.
Freeze-TCP (21) Postech Postech DP&NM LabDP&NM Lab
Warning PeriodFreezeTCP (3)
• Warning period.– How much in advance of the disconnection should the
receiver start advertising ZWA?– Ideally, long enough to ensure that exactly one ZWA
get across to the sender.– Longer : idle time prior to disconnections– Small : sender’s congestion window to drop.– RTT is reasonable. ( ref : Experimental result )– Only useful if a disconnection occurs while data is
being transferred.
Freeze-TCP (22) Postech Postech DP&NM LabDP&NM Lab
TR-ACK -1Freeze-TCP (3)
• Triplicate Reconnection ACKs– ZWPs are exponentially backed off. – The possibility of idle time after reconnections.– To avoid this idle time, TR-ACKs implements.– Effect of standard TCP.
Freeze-TCP (23) Postech Postech DP&NM LabDP&NM Lab
TR-ACK
ZWP
ZWP
sender
receiver
Receiver window open
Sending again
Freeze-TCP (24) Postech Postech DP&NM LabDP&NM Lab
Estimate performance -1Freeze-TCP (4)
• Idle period avoided.– W • ts ≥ RTT , W ≥ RTT / ts
: ts ≈ packet-size / band width , W : sender window size
Receiver
SenderRTT
W unACKed packets can be sent
ts
Freeze-TCP (25) Postech Postech DP&NM LabDP&NM Lab
Estimate performance -2Freeze-TCP (5)
• Increased throughput.
Freeze-TCP (26) Postech Postech DP&NM LabDP&NM Lab
Experimental result
• Modifying the Linux 2.1.101 TCP source code.• Emulate the mobile host in a PC.• Freeze-TCP is not worsen performance by a
noticeable amount.
Freeze-TCP (27) Postech Postech DP&NM LabDP&NM Lab
Conclusion and Discussion -1
• To enhance TCP performance in the present of disconnections and reconnections.
• True end-to-end signaling scheme.• Unnecessary intermediaries’s help.• Easy changing TCP code at receiver side • Easy to implement. • Almost no overheads and tradeoffs.• Complete inter-operability with existing infrastruc
ture is guaranteed.
Freeze-TCP (28) Postech Postech DP&NM LabDP&NM Lab
Conclusion and Discussion -2
• Full rate with old window size on entering new unknown environment or not.
• Needs at receiver to predict impending disconnections. ( pro-active action/simulations )