Re: [amqp-bindmap] [SCTP Binding]

[Raphael Cohn <raphael.cohn@stormmq.com>]

Mobiles do lose tcp frequently. But given one should be running tls on
that sort of public infrastructure, conn overhead is far higher than a
couple of sasl frames. Far higher. Of course, if one is using tls, you
can then use session caches and bypass sasl altogether for
re-connection... Or use another tls layer mechanism.

I would argue though that it's a very bad idea to use a sctp
connection's streams for multiple protocols. Therein lies the route to
madness.

Raphael Cohn
Chief Architect
raphael.cohn@StormMQ.com
StormMQ Limited

UK Office:
Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN,
United Kingdom
Telephone: +44 845 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 07175657
StormMQ.com

On 30 Jan 2013, at 19:09, Rafael Schloming <rafaels@redhat.com> wrote:

> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>