[Sis-ams] Predictability concerns with AMS, and other questionstoo

[Scott Burleigh]

Marek Prochazka wrote:

>Hi Scott,
>  
>
>>When a node publishes a message, the message is sent to N 
>>destination nodes where 0 <= N <= (cardinality of the message 
>>space).  Each message transmission utilizes a transport 
>>service that is implicitly chosen for that particular 
>>transmission based on the service mode specified by the 
>>subscriber.  The only possible guarantees on delivery and 
>>performance for each individual transmission are those 
>>provided by the underlying transport service. 
>>    
>>
>I understand that you rely on the underlying service. But still, the AMS
>doesn't give the user any chance to reason about delivery. In other
>words, being implemented on top of a transport service, the AMS will get
>exact failure codes if they are available, but there is no way to get
>them from AMS. Or is it?
>  
>
>>The key concept here is that AMS by design gives the 
>>application a great deal of control over - and, 
>>correspondingly, responsibility for - message exchange 
>>performance.  Application developers still have to give some 
>>thought to exactly what is important to them, because nothing 
>>comes for free - retransmission increases the chance of 
>>delivery but increases latency, real-time performance is only 
>>possible in networks of limited scope, bandwidth reservation 
>>can degrade network performance, and so on
>>- and AMS declines to make all these design trade-offs in 
>>advance and lock all developers into those decisions.
>>
>>Summing up: AMS is no substitute for engineering.  There's no 
>>magic here.
>>    
>>
>As a part of the project, we will have to implement a distributed
>consensus algorithm on top of MTS or AMS. The more the
>communication/transport protocol is reliable (bounded message loss,
>bounded delays, etc.), the easier is to design and write a solution that
>solves the consensus problem.
>
>It seems to me that there is basically no delivery guarantee provided by
>either MTS or AMS.
>  
>
This is a good point to explore a little further, Marek.  A lot depends 
on exactly what we mean by "delivery guarantee".

Let's narrow in on a specific case.  Suppose a node publishes a message 
on a subject for which there are five subscribers.  If two of the 
subscribers are reachable by TCP but three of them are only reachable by 
UDP -- that is, they have only got UDP sockets open -- then obviously 
AMS cannot guarantee that the published message will be delivered to all 
subscribers.  What behavior would you *like* to see in this case?  That 
is, what specific sort of delivery guarantee would help you implement 
your distributed consensus algorithm?

The AMS specification certainly isn't frozen at this point, but one 
could argue that in order to accomplish everything it's currently 
required to do it has already become fairly complex and challenging to 
implement.  If there are features that can be added that would provide 
the behavior you need without degrading other capability or making the 
protocols a lot more complex then we should think seriously about adding 
them.

Scott