Subject: [Rserpool] Another data channel issue: failover of messages in basic mode?

From: "Phillip T. Conrad" <[email-masked]>
Date: Tue, 01 Apr 2003 17:03:52 -0500

Dear Colleagues:

In my discussion with Qiaobing about renaming the two modes for RSerPool 
services to "basic" and "enhanced", another issue that Qiaobing raised is 
whether in basic mode, automatic failover of messages can be provided as a 
service.

My first inclination is to say "no", however on further reflection, I said 
I would think about it.  So here are some thoughts about that, and an 
question to pose to the working group.

My first reaction is to say that what you get in basic mode is the 
selection of a server that is better than what you would get with DNS 
because it

- is based on reports from PEs and PUs about server health
- can based on a policy value (for load sharing)

(and maybe some other benefits that the working group can help me to 
recite; I'm definitely inviting help with the text here!)

But in basic mode, you do not get automatic best-effort message failover, 
because that requires you to be sending over a transport that is mapped to 
the RSerPool API.   Message failover comes in enhanced  mode, along with 
all the other goodies (business cards, etc)

However, Qiaobing pointed out, correctly, that you do not need the control 
channel to do message failover (now that application layer acks are gone); 
all you need is someway to tell the RSerPool API how to map the the 
RSerPool data transmission primitives (e.g. the equivalent in your 
particular API of the data.send primitive) to the transport protocol in 
question (whether that be SCTP, TCP, UDP, DCCP or whatever).   This mapping 
is so trivial that it almost doesn't even need to be mentioned, and if we 
provide it, this will allow failover of any message that has not yet been 
put on the wire.

Of course, except for with SCTP, you will not get any message failover of 
messages that have already been submitted to the transport layer and were 
never transmitted, since no protocol other than SCTP supports "retrieval" 
(note that because application layer acks were removed, you don't even get 
that with the TCP mapping layer anymore.)

My question is this: how often would it be, for example, in UDP, that you 
would have any messages that had not yet been put on the wire?     The only 
time I can imagine an RSerPool implementation not putting something on the 
wire immediately is if the underlying transport layer socket is not 
writable (determined for example via a select() system call in the sockets 
API, or an EWOULDBLOCK error, etc.)      My understanding is that 
this  typically happens when the transport endpoint is restricted because 
of cwnd or rwnd, and then also runs out of buffer space, and the socket 
runs out of buffer space too.

This could realistically happen with SCTP or TCP particularly if the 
application on the peer end is slow to read and process data.  But how 
realistic is it for UDP?   My guess is that is will never happen, since UDP 
is never blocked due to cwnd or rwnd.

So, I while I can concede Qiaobing's point that a message channel is not 
necessary to provide I'm not sure there is a practical need to provide for 
message failover in basic mode.    I'd like to keep basic mode as basic as 
possible, just for cleanness of the architecture.

I'd like to invite the rest of the working group to comment on these two 
possibilities: should we

(1) allow for message failover in basic mode for messages not yet put on 
the wire (which means, conceivably, any arbitrary transport protocol)?

OR

(2) restrict message failover to enhanced mode (SCTP and mapped TCP)?

Thanks,
Phill

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool