Re: BEEP as OCP transport

[Marshall Rose <mrose@xxxxxxxxxxxxxxxx>]

thanks for the clarification.

> Simplified transport requirements of the current OCP core, in each
> flow direction (processor to server and server to processor), are:
> 
> 	- efficiently send possibly large application messages and
> 	  metadata (blobs), with possibly more than one blob being
> 	  sent at a time; parts of each blob should be
> 	  delivered in sent order
> 
> 	- send usually small OCP "control" messages related
> 	  to the dataflow above, at any time; control messages should
> 	  be delivered in sent order
> 
> We agree that the first approach (one channel per OCP connection) does
> not work without hacks because it does not support the "at any time"
> part.
> 
> Using multiple channels per OCP connection (one for control and one or
> more for data/metadata) would work, but, as I said, I am worried about
> synchronization problems between data and control channels. My
> understanding is that BEEP does not guarantee that two messages sent
> on two channels will arrive in the order they were sent. Please
> correct me if I am wrong.

that is correct, channels on the same session, are effectively
parallel. if you need to synchronize them, you can, you have to define
messages to do so for your protocol.

    
> I think we are on the same page now. It would be great to hear from
> others as well. Is anybody able to follow my lame attempts at
> explaining the problem? Does anybody have horror stories to tell about
> FTP (other than firewall problems)? Is there a reason we should not
> use multiple BEEP channels per OCP connection _if_ BEEP is selected as
> a transport protocol?
    
if the answer is "FTP", then the wrong question has been asked.

    
    
> Marshall, is it correct to say that opening a new BEEP channel can be
> "cheap", even if we want to use encryption and such? Multi-channel
> solution appears to be more elegant than my hack, but I am worried
> about the cost on performance. If an OCP connection (all BEEP
> channels) needs to be encrypted using, say TLS, does it mean that an
> OCP agent would have to re-negotiate encryption parameters for every
> channel it needs to open? This is not a show-stopper (because we could
> keep channels persistent), but we need to understand the costs. It
> would be nice if we could say "and for this new channel, use the same
> parameters we negotiated for that old channel", but we cannot do that
> in general, can we?
    
each beep session has a single encryption/authentication context. you
negotiate it at the start of the session, and it applies to every
channel thereafter, e.g.,
    
	beep channels
	beep frames
	tls packets
	tcp segments
    
all traffic on all channels goes over the same tls session.
    
/mtr