Subject: RE: TCP vs UDP for Safe Failover

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Wed, 12 May 1999 09:04:33 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
-----------------------------------------------------------------
Regarding the TCP/UDP vs TCP only debate, I think most of the issues
have been covered. But let me chime in anyway. And, I think I'm going
to chime in to contracdict what I've been pushing for all along (UDP).

The more I think about this, the more I feel that we DON'T need
UDP. Perhaps I'm forgetting something major here and I orginally started
writing this message believing we needed UDP. But as I started writing,
I thought why? And started rewriting the message.

What are the out-of-band POLLs used for?

They really just tell us that the peer server is either back or up (not
down). But, why do we need to know this "immediately"? After all, the Safe
Failover protocol is designed not to require tight coupling between
the servers. And, when the servers are "idle", we do want to know that
the peer is alive, but if they are idle, we don't have a flow control
issue and the polls will flow freely.

If one server goes down and there is still data in the pipe, we'll
read it eventually or our send will eventually fail.

Looking at a couple of possible situations:

a. Primary is sending LOTS of binding updates to secondary, but
Secondary goes down. Suppose the window was closed to primary (so it
can't send more). Primary will find out secondary is down because
either the connection is reported down or the primary won't receive
SOMETHING from the secondary within some time limit and thus take
the conenction down.

b. Both servers are idle and one goes down. Again, the poll timers
will trigger and there won't be any response from the peer within
some fixed time period. So, other server will reset connection and
retry.

c. Once the servers are up and running, when they exchange lots of
data, is when state changes don't happen. Hence, the need to exchange
POLLs to communicate state changes are primarily used when the
connection isn't being used for data exchanges (hence no flow control
issues in general).

d. The reasons for using the POLL/POLLACK might disappear as well.
One of the reasons for using that was to assure bi-directional
communication with UDP (since it is possible in UDP to be able
to receive packets from someone you can't send to). That is NOT
possible in TCP, since the connection couldn't be established in
that case. So, we might change POLLs to be more like "KEEPALIVE"
messages and drop POLLACK.

So, let's think this over some more and consider why we need immediate
or out-of-band notification? What's the big deal if there are lots of
binding updates in the "pipe"?

My main reason for wanting UDP was that it was much eaiser to implement.
No non-blocking socket calls. No isuses with having to deal with not
being able to send. No blocking/deblocking of "records". AND, I felt
that we could continue using the standard BOOTP port instead of requiring
a different port, as these are unicast packets (not broadcast). So, no
new sockets to deal with. And, if we ever extended the protocol to cover

more than two servers, it was lower cost in not having to have a socket
(connection) for each pair of servers.

Again, I might be brain dead and missing something critical here. And,
some folks might be unhappy as I was one of the big proponents of UDP
(for the above stated reasons, not typically for protocol related issues).

- Bernie Volz
  Process Software

BTW: To address some of the issues of using TCP, like the connection
collision detection (see section 6.8 in BGP RFC 1771) we can just
have both servers drop the connection started by the secondary.