Wrapping ServerSide TCP to Mask Connection Failures - PowerPoint PPT Presentation

Loading...

PPT – Wrapping ServerSide TCP to Mask Connection Failures PowerPoint presentation | free to download - id: 81df4-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Wrapping ServerSide TCP to Mask Connection Failures

Description:

Wrapping Server-Side TCP to Mask Connection Failures. Lorenzo Alvisi UT Austin ... Ayman El-Khashab UT Austin. Keith Marzullo UC San Diego. Dmitrii Zagorodnov ... – PowerPoint PPT presentation

Number of Views:34
Avg rating:3.0/5.0
Slides: 16
Provided by: dzag
Learn more at: http://www.cs.ucsb.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Wrapping ServerSide TCP to Mask Connection Failures


1
Wrapping Server-Side TCP to Mask Connection
Failures
  • Lorenzo Alvisi UT Austin
  • Thomas Bressoud Lucent Bell Labs
  • Ayman El-Khashab UT Austin
  • Keith Marzullo UC San Diego
  • Dmitrii Zagorodnov UC San Diego

2
Motivation
  • Reliable services are extremely desirable
  • Techniques exist for building reliable services
  • Primary backup
  • Active replication
  • Rollback recovery
  • These techniques are hard to apply when
    fault-tolerance is retrofitted on existing
    systems
  • Many client-server systems use TCP
  • Break of TCP connection has side-effects
  • Example BGP, H.323 control connections

3
Problem
  • Cannot change the client

4
Application-level Approach
TCP
IP
IP
TCP
Client
Server
TCP stream
  • Use application-level (end-to-end
    fault-tolerance) or middleware-based replica
    coordination
  • Pros efficient, portable
  • Problem requires changing software on clients

5
Proxy-based Approach
TCP
IP
TCP
IP
Client
Server
TCP stream
  • Solution Use proxy on the network path
  • Pros client is unchanged
  • Problem introduces single point of failure and
    potential performance bottleneck

6
TCP Replication Approach
IP
TCP
TCP
IP
Client
Server
TCP stream
  • Modify the TCP implementation on the server to
    accommodate reestablishing connections
  • Pros changes only to server, no single point of
    failure
  • Problem very difficult to deterministically
    replicate TCP

7
Our Approach FT-TCP
TCP
IP
TCP
Client
IP
Server
TCP stream
  • Wrap the servers TCP driver on top and bottom
  • No changes to TCP, no changes to client, no
    single point of failure
  • Question is this feasible?

8
Normal Operation
  • South Side Wrap (below TCP)
  • each incoming packet is sent to the logger
  • on each outgoing packet with payload
  • the acknowledgment number is modified to
    acknowledge only what has been logged
  • the window is increased to account for the
    difference between what has been processed by TCP
    and what has been logged
  • empty packets may be delayed until data they are
    acknowledging has been logged
  • North Side Wrap (above TCP)
  • for each read( ) the read length is sent to the
    logger
  • on each write( ) it blocks until all read lengths
    are logged

9
During Failure
  • Failure needs to be detected
  • as close( ) on the socket
  • or as machine crash
  • Connection with client must be maintained
  • keeps it alive by sending empty acks with window 0

10
Recovery Process
  • Another server process is started
  • Key assumption this process will behave the
    same way as the failed process given the same
    network input
  • South Side Wrap
  • Initiates a connection to the server on behalf of
    the client
  • The difference between servers new initial
    sequence number and the old one is saved in
    delta_seq
  • North Side Wrap
  • Replays data from the log via read( ) calls
    returning the same read lengths as during
    previous execution
  • All write( ) calls sending old data are ignored
  • When the log is exhausted and all old data is
    resent the normal operation resumes

11
Experiments
1 MB
12
Throughput
  • Throughput achieved relative to normal TCP under
    different net configurations
  • With a fast logger throughput is statistically
    undistinguishable
  • With a slower logger throughput decreases
    significantly
  • Problem SSW delays acknowledgments
  • Degrades TCP performance
  • Think fast sender, slow receiver

13
Performance Challenge
  • Challenge Wrap TCP so that we are not
    interfering with its ability to obtain good
    performance
  • Idea Send additional acks to keep the client
    better informed about available buffer space on
    the server
  • Consider three acknowledgement strategies
  • Lazy - delay empty ack packets, no new ones are
    generated
  • Eager - send an ack packet for every logged data
    packet
  • Conditional - send additional ack packet when
    doing otherwise may cause the client to stall

14
Throughput All Strategies
15
Conclusions
  • Traditional fault-tolerance is insufficient
  • FT-TCP solves the network part of the puzzle
  • indistinguishable from non-fault-tolerant TCP
  • Further details in the paper

16
Replication Details
  • Placement of replicas determines the types of
    failures that our system will tolerate
  • i.e. process failures, machine crashes, network
    partitions
  • Replication method affects performance of the
    system and its storage requirements
  • running replicas concurrently, side-by-side
  • allows for fast fail-over
  • slow under normal operation and/or potentially
    expensive
  • creating a replica on-demand
  • small overhead during normal operation
  • longer fail-over and larger storage required

17
Connection Prefix Example
connection establishment
18
Normal Operation
19
Recovery Process
delta_seq200-300
flag seq len win ack
read()
write()
20
TCP Acknowledgements Problem
0
1
2
21
Lazy Ack Strategy
0
22
Eager Ack Strategy
0
About PowerShow.com