[Nsi-wg] Message Delivery Layer

[Henrik Thostrup Jensen]

On Thu, 6 Dec 2012, Jeroen van der Ham wrote:

> It seems that in the current document we have sections on the MDL and 
> MTL. The MTL is deemed to be out of scope, and it is recommended to be 
> "TCP/IP-HTTP-XML (such as SOAP)". Which I would scrap, and just put in 
> SOAP, since NSI does not support any other TCP/IP-HTTP-XML stack.
>
> Given that TCP, HTTP and SOAP already provide more than enough delivery 
> assurance, I have to wonder why we actually need that extra conceptual 
> layer in the Message Delivery Layer. It already is basically outsourced 
> to those layers anyway. And for the few cases where upper layer logic is 
> required to make sure that a request is handled correctly, we turn to 
> the State Machine in the form of acknowledgements.

I agree with what is being said here.

Wrt. to the MDL (and this is to Guys response as well), I'm fairly sure it 
was a conceptual thing to help explaining how an aggregator would work.

It cannot be implemented in the simplistic way the slides presents it (an 
isoloated layer) as one needs to keep track of the states of the 
subconnections and in a persistent ways if one wants a sensible working 
system. There is something that reminds of the the MDL in the OpenNSA 
aggregator, but there are a lot of details to it. Of course the MDL is 
described in a very generic way open to a lot of interpretation, but I'm 
not sure that improves the situation. (sorry of this section is a bit hard 
to understand).

> I know that the State Machine is currently still being improved. But did 
> we also take the suggestion to make all short exchanges synchronous, and 
> to allow optional acknowledgement for longer asynchronous exchanges? 
> This would make it much simpler to use NSI in cases with limited 
> connectivity (firewalls/clients/NAT etc.)

Sync/Async doesn't really chage the state machine as I see it. I could be 
wrong though.

I'd like more synchronous messages, but given the way things are wired 
together, it is difficult to do. I've argued for a generic state change 
request (replacing provision, release and terminate), along with a 
publish-subscribe mechanism earlier. This would also allow third party 
requests for connection updates, where they are currently forced to do a 
query.

However we also have a lot of people asking/waiting for a stable version 
of NSI to implement, as it is currently very much a moving target. I don't 
think these changes are particularly complex, but IMHO the group has not 
been very open to changes in the protocol core mechanisms.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet