Re: [amqp-bindmap] [SCTP Binding]

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

In the absence of anything else, I'd implement TLS atop SCTP as follows:-

Have a 'pair' of unidirectional streams for each required 2-way communication;

construct the pair by convention, preferably stream 0 out pairs stream 0 in, etc;

substitute alternative ssl_read / ssl_write function implementations if using OpenSSL that cal sctp_sendmsg / sctp_readmsg, and treat sctp as if it where a stream (TLS is record delimited, but that's too complex too map as openssl et al assume a stream)

use as a pair

So... this requires TLS set up for EVERY stream pair. Slow, inefficient, etc.

Raphael Cohn
Chief Architect, stormmq

Secretary, OASIS AMQP Standard
raphael.cohn@stormmq.com

+44 7590 675 756

UK Office:
Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, 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 29 January 2013 15:38, John O'Hara <john@rjohara.com> wrote:

TLS is more interesting - would you maintain a separate TLS session
for each SCTP stream???
I know there's been some stuff written about this on the SCTP sites -
would be interesting to see where that landed.

On 29 January 2013 14:41, Raphael Cohn <raphael.cohn@stormmq.com> wrote:
> I'd hope not... by 'special stream' I just mean that one expects to receive
> SASL then connection open on SCTP stream 0 -  which always exists. After
> that, it really doesn't matter, although it would be nice to have connection
> close on stream 0. In effect, stream 0 is what you get if you bind a socket
> to SCTP w/o doing anything special. One needs some sort of convention 'at
> start up' to know how to proceed.
>
> Raphael Cohn
> Chief Architect, stormmq
> Secretary, OASIS AMQP Standard
> raphael.cohn@stormmq.com
> +44 7590 675 756
>
> UK Office:
> Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, 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 29 January 2013 14:29, Kritikos, Alex <Alex.Kritikos@softwareag.com>
> wrote:
>>
>> Hi all,
>>
>> Just a question to all… if we enforce a dedicated stream with some special
>> meaning, would that not affect future bindings to other transports? Or will
>> there be a registry  / some sort of handshake to define the characteristics
>> of a special stream?
>>
>> Thanks,
>>
>> Alex Kritikos
>> Senior Director
>> Software AG
>>
>> On Jan 29, 2013, at 4:21 PM, Raphael Cohn <raphael.cohn@stormmq.com>
>>  wrote:
>>
>> Andreas,
>>
>> Being stimulated by your questions.
>>
>> Connection Management
>> I would prefer to have a dedicated stream for this. It's decidedly easier.
>> It's also worth noting that we can send some out-of-band data with a
>> message, such as an opaque 32-bit number. This could be an useful way to do
>> the 'We're AMQPxxxx' equivalent in SCTP. Frankly, a client star
>>
>> Session
>> Either. The choices we make in SCTP are whether we want to make it easy to
>> take an existing implementation for TCP and make it work on SCTP (easy; just
>> use one stream and multiplex, we can have a standard in a week that can be
>> implemented in a day), or use multiple streams for multiple sessions (not
>> too hard, but more work for everyone, but with other potential advantages).
>> We might also want to consider if we ever want 'peel-off', where a stream
>> can then become its own dedicated separate socket - useful for getting
>> epoll, select, etc, to do per session events for high bandwidth sessions,
>> rather than per connection, but rather hard to get one's head round.
>>
>> Regardless, I'm not in favour of mixing AMQP traffic on these streams with
>> other protocols. Given the lack of first class support in most network
>> eventing frameworks (epoll, etc) for per stream events, it would require
>> some truly horrible server logic.
>>
>> Raph
>>
>> Raphael Cohn
>> Chief Architect, stormmq
>> Secretary, OASIS AMQP Standard
>> raphael.cohn@stormmq.com
>> +44 7590 675 756
>>
>> UK Office:
>> Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, 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 29 January 2013 13:48, <Andreas.Moravec@deutsche-boerse.com> wrote:
>>>
>>>
>>> Without knowledge of SCTP usage for legacy amqp versions
>>> (pre-OASIS-standard),
>>> I have more general questions:
>>>
>>> - Connection management.
>>>    Need of dedicated management stream?
>>>    E.g., the first stream for protocol header, open, close
>>> - Session.
>>>    Each session requires its own SCTP stream?
>>>    Or alternatively/additionally multiplexing like on a TCP connection?
>>> - Ordering of operations.
>>>    Handling of pipelined open, simultaneous close and session end?
>>>    Maybe, pipelining has to be restricted or disallowed when using
>>>    multiple streams. E.g. session can only be begun after connection
>>>    "open" has been acked by the counterparty's "open" and
>>>    close may only be sent after ending the sessions has been acked
>>>    by the counterparty's "end" for all sessions.
>>>
>>> Andreas
>>>
>>> <robert.godfrey@jpmorgan.com> wrote on 29.01.2013 13:22:41:
>>>
>>>
>>> > 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.
>>> >
>>> > 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).
>>> >
>>> > 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?
>>> >
>>> > -- Rob
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Deutsche Börse AG
>>> Chairman of the Supervisory Board/
>>> Vorsitzender des Aufsichtsrats:
>>> Dr. Joachim Faber
>>> Executive Board/Vorstand:
>>> Dr. Reto Francioni (Chief Executive Officer/Vorsitzender),
>>> Andreas Preuss (Deputy Chief Executive Officer/
>>> stellv. Vorsitzender), Frank Gerstenschläger,
>>> Gregor  Pottmeyer, Hauke Stars, Jeffrey Tessler.
>>> Aktiengesellschaft with registered seat in/mit Sitz in
>>> Frankfurt am Main.
>>> Commercial register/Handelsregister:
>>> Local court/Amtsgericht Frankfurt am Main HRB 32232.
>>>
>>> -----------------------------------------
>>> Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte
>>> Informationen.
>>> Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte
>>> sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren
>>> dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen
>>> ist nicht gestattet.
>>>
>>> The information contained in this message is confidential or protected by
>>> law. If you are not the intended recipient, please contact the sender and
>>> delete this message. Any unauthorised copying of this message or
>>> unauthorised distribution of the information contained herein is
>>> prohibited.
>>>
>>> Legally required information for business correspondence/
>>> Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz:
>>> http://deutsche-boerse.com/letterhead
>>
>>
>>
>