Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC

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

Rob, Adding to your questions and observations:- 1 AMQP / Open I think this is soluble if we assume that stream 0 is special, and only after SASL tunnelling / Open has been received, is the connection open. 2 Framing I agree, but I would like to check that the common POSIX APIs make it possible to get at message size, etc easily. I assume we're using a stream per session? 3. Closing a Connection If Stream 0 is 'special', then when close is received on it, close happens Or we could simply make it such that close received on ANY stream closes the connection. AMQP is robust to this sort of communication failure. 4. Security SASL I, for one, would want to continue to use SASL. The problems of total ordering and sessions affect this, too, but I believe this is soluble if we we went with the 'only one stream until open received' paradigm above. An alternative is to just use one SCTP stream and continue as before, multiplexing sessions. Whilst this seemingly loses some of SCTP's advantages, we do gain a VERY simple transition for existing servers - simply replace the constants specified to bind() on POSIX, for example. We do still retain most of the advantages - multi-homing, better acks for dodgy networks, less chance of DoS, etc. TLS There is an RFC for TLS over SCTP, and there are implementations / patches, arguably not as well maintained, for OpenSSL and GnuTLS. Whether these work with more than one SCTP stream I can't confirm. It seems the GnuTLS patch does. 5 Other Concerns Max Sessions We need to look at max session negotiation in open, because any SCTP connection is going to specify this (if opened as one-to-many) at bind, eg in setsockopt() -  http://www.linuxforu.com/2011/12/socket-api-part-5-sctp/ may help here. 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 12:22, Mr. Rob Godfrey < robert.godfrey@jpmorgan.com > 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. 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

From: Raphael Cohn [ mailto:raphael.cohn@stormmq.com ] Sent: Tuesday, January 29, 2013 12:54 PM To: Godfrey, Robert X Cc: amqp-bindmap@lists.oasis-open.org Subject: Re: [amqp-bindmap] [SCTP Binding] > Rob, > Adding to your questions and observations:- > 1 AMQP / Open > I think this is soluble if we assume that stream 0 is special, and > only after SASL tunnelling / Open has been received, is the > connection open. This works if you say you have to buffer all incoming messages on other streams until you see the open on stream 0... is that a position we are happy with? Also, is everybody happy with the idea of the “special” stream 0... Matt’s idea of being able to multiplex AMQP and non-AMQP traffic on the same SCTP association (but on different streams) would not seem to play well with “special” streams. > 2 Framing > I agree, but I would like to check that the common POSIX APIs make > it possible to get at message size, etc easily. I assume we're using > a stream per session? > 3. Closing a Connection > If Stream 0 is 'special', then when close is received on it, close > happens > Or we could simply make it such that close received on ANY stream > closes the connection. AMQP is robust to this sort of communication > failure. I’m not sure that a special stream adds anything to the party here. The issue is only about the fact that no longer can be assured that our “close” can overtake data we’ve previously sent on other streams. All one can do is to attempt to ensure that all sessions are cleanly ended before we issue a close. However if either peer may initiate a session, there is no way to guarantee this. > 4. Security > SASL > I, for one, would want to continue to use SASL. The problems of > total ordering and sessions affect this, too, but I believe this > is soluble if we we went with the 'only one stream until open > received' paradigm above. > An alternative is to just use one SCTP stream and continue as > before, multiplexing sessions. Whilst this seemingly loses some > of SCTP's advantages, we do gain a VERY simple transition for > existing servers - simply replace the constants specified to > bind() on POSIX, for example. We do still retain most of the > advantages - multi-homing, better acks for dodgy networks, less > chance of DoS, etc. Obviously SASL mechanisms which provide an encryption layer are not suitable (again due to the lack of total ordering over the connection). > TLS > There is an RFC for TLS over SCTP, and there are implementations > / patches, arguably not as well maintained, for OpenSSL and > GnuTLS. Whether these work with more than one SCTP stream I can't > confirm. It seems the GnuTLS patch does. IIRC SCTP streams are unidirectional (though for every stream there is a similarly numbered stream operated in the opposite direction). TLS would require bidrectional communication which would require the streams to be paired together at the SCTP level... I’m not sure how this would play with an AMQP Channel <-> SCTP Stream mapping. > 5 Other Concerns > Max Sessions > We need to look at max session negotiation in open, because any > SCTP connection is going to specify this (if opened as one-to-many) > at bind, eg in setsockopt() -  > http://www.linuxforu.com/2011/12/socket-api-part-5-sctp/ may help > here. Yes Max sessions and Max Frame size might be determined at the SCTP level (or at least bounded above by the SCTP association). > 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 12:22, Mr. Rob Godfrey <robert.godfrey@jpmorgan.com> 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. 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 This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email .

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

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

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

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

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 >> >> >> >

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 >> >> >> >

The other option is DTLS... which is supported in newer versions of OpenSSL and GnuTLS. I know very little about it. 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:54, Raphael Cohn < raphael.cohn@stormmq.com > wrote: 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 >> >> >> >

DTLS does seem to be the “right” answer... though I am unfamiliar with the extent of its support (e.g. I’m not aware of support directly from Java).
 
Setting up individual TLS sessions on each SCTP stream seems particularly unattractive.
 
-- Rob
 

From: amqp-bindmap@lists.oasis-open.org [mailto:amqp-bindmap@lists.oasis-open.org]
On Behalf Of Raphael Cohn
Sent: Tuesday, January 29, 2013 3:56 PM
To: John O'Hara
Cc: Kritikos, Alex; amqp-bindmap@lists.oasis-open.org
Subject: Re: [amqp-bindmap] [SCTP Binding]

 
The other option is DTLS... which is supported in newer versions of OpenSSL and GnuTLS. I know very little about it.




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:54, Raphael Cohn < raphael.cohn@stormmq.com > wrote:
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
>>
>>
>>
>



 





 





This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

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

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 >