Re: [amqp-bindmap] [SCTP Binding]

[Rafael Schloming <rafaels@redhat.com>]

On Tue, 2013-01-29 at 04:22 -0800, Mr. Rob Godfrey wrote:
> So I guess my open questions on the SCTP Binding are
> 
> 1) How do we mark initiation of the AMQP communication
> 
> In TCP we use a header AMQPxxxx ... which TCP guarantees will arrive before any subsequent frames.  In SCTP am I correct in believing this guarantee would only hold true if all communication was on the same SCTP stream.
> 
> The open frame similarly is defined as having to be sent before any other AMQP traffic on the connection. 
> 
> 2) Framing.  I believe that we can do away with the need for AMQP Framing when using SCTP.  The SCTP message carries all information that is currently held in an AMQP frame with the exception of the unused extended header.  Are others comfortable with this approach.

How would max frame size translate? Does SCTP have such a notion? If so,
is it shared by all the streams or independently negotiated?

> 3) Closing a connection. Similar issues to opening in that we don't have the same total ordering guarantees.  In the case of a clean shutdown this is probably not a significant issue (all AMQP Sessions will have been "end"ed prior to the close being issued... the peer can take note of the close, and wait until all open sessions are ended... or timeout after some waiting period).  (There may be a vanishingly small corner case where a sender asyncronously begins, operates on, and ends a session... and this entire sequenec is "overtaken" by the close). 

Strictly speaking we don't actually need total ordering to do open/close
very similarly to TCP. Hypothetically you can simply repeat the
open/close frame on every stream and let the first one to arrive at the
remote endpoint win.

While this admittedly might seem hacky from one perspective, if you
consider that both the open and close frames simply announce information
about the communicating endpoint and indicate the beginning/end of an
ordered sequence of frames, it is in some ways a fairly natural fit. In
fact depending on the answers to some of the other questions, e.g. does
each stream have its own frame size, can streams run different
protocols?, etc, then it might not be as redundant/hacky as one might
think at first.

> 
> 4) Security... will we continue to use SASL... if so how does the layering work.  We also need to define the TLS equivalent layer.
> 
> What other areas have I ommitted?

Unlike the open/close case where I think there are a bunch of workable
options, this seems like the most difficult part of mapping the overall
AMQP connection setup/teardown. (I'm assuming we wouldn't want to repeat
the whole SASL exchange over every single stream.) However, I think it's
worth pointing out though that this problem isn't unique to SCTP. Mobile
devices lose TCP connections frequently and would dramatically benefit
from a lighter weight way to (re)establish an authenticated connection.

--Rafael