RE: [amqp-bindmap] [SCTP Binding]

["Godfrey, Robert X" <robert.godfrey@jpmorgan.com>]

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.