Hi Steve, Here are some ideas
regarding the use cases for AMQP over SCTP, as you requested. Message monitoring- Problem:
It is very difficult to correlate application performance issues with
network performance issues when there is no mapping between application
message boundaries and transport layer message boundaries, as is the
case with TCP. Generally, debugging means either intrusively inserting a
proxy, harming performance, or mirroring a large amount of data for
offline analysis. Neither is ideal for debugging.
- Solution:
Imagine a network engineer being able to tell an application engineer,
"I saw 30 AMQP messages cross this point" and even be able to tell which
performatives they were. There can be true collaboration in
identifying mission-critical application performance issues.
WAN diversity
- Problem: If
a WAN link goes down, applications need lots of complex logic to detect
and account for it. The alternative is to place a proxy at the WAN
location, which is quite intrusive and creates additional management
points that add complexity.
- Solution: SCTP allows multiple
addresses on either side of the connection. If used correctly, this
means that multiple WAN providers (generally contracted by large
enterprises for redundancy anyway) can be used on a single AMQP link, improving
reliability – if one provider fails, the other can be used, even if its
IP address is in a completely different network location.
Mobile endpoints
- Problem:
If an AMQP client is on a mobile device, its IP address could change as
it moves. This normally means that any such connections would be
broken, and if the client reconnects it will reenter the connection
negotiation sequence. This can add significant overhead if the mobility
is frequent, as well as lead to more complexity of application logic.
- Solution:
If such motion is predictable, then a multiple-address association
using SCTP (as in the WAN diversity use case) can be created. There is
also an existing SCTP extension to "add" an address to an association
after it has been created, so as to prepare for the mobility event.
Once the event happens, it will be treated like a WAN link failure and
the new address will seamlessly be used.
Message-level encryption
- Problem
1: Conventional security solutions like SSL or TLS make it difficult to
analyze the performance of application layer protocols. Generally one
can only get statistics as to the number of packets and/or bytes sent,
which doesn't translate into useful metrics for the application owner.
- Problem
2: Message-level encryption schemes, when proposed, end up not
providing a solution to this because of an unrelated reason – the
"message monitoring" problem above.
- Solution: The "chicken and
egg" can be resolved by using both SCTP with message-level encryption
(possibly based on DTLS). To actually provide a benefit, the datagram
would need to be considered as only the data after the AMQP frame header
and therefore would be different from the existing DTLS over SCTP.
QoS- Problem: When sending
unordered data, some is more important than others, and should be
prioritized. With TCP, only the entire connection can be prioritized,
since ordering is enforced.
- Solution: With SCTP, unordered
data is supported, and datagrams marked as such could also be marked
with DSCP so that network devices will appropriately prioritize such
traffic when there is congestion.
--
Sanjay Hi Sanjay, Angus, In
yesterday's AMQP BINDMAP TC call, we were talking about the need to
ensure we have the right set of requirements for the AMQP/SCTP binding
before getting too far down the design road. Since you two were pretty
enthusiastic about SCTP in the past and have a reputation for being very
knowledgeable on the subject, I was hoping you would be able to get
together requirements and use cases behind them for the AMQP/SCTP
binding and forward them to the amqp-bindmap@lists.oasis-open.org list. Could
you please commit to supplying your ideas in the next week? Thank
you, Steve Huston --------------------------------------------------------------------- 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
|