[Nsi-wg] Message Delivery Layer

[Vikas Deolaliker]

Sorry to butt in.. first time poster ...

If you have decided to use SOAP with HTTP binding, WS-RM (ReliableMessaging) will ensure message delivery. Perhaps this layer (MDL) is referring to that? 


Vikas

________________________________
 From: Inder Monga <imonga at es.net>
To: Jeroen van der Ham <vdham at uva.nl> 
Cc: NSI Working Group <nsi-wg at ogf.org> 
Sent: Thursday, December 6, 2012 7:26 AM
Subject: Re: [Nsi-wg] Message Delivery Layer
 

Hi All,

I haven't had a chance to read the entire thread on this. 

The MDL layer essentially handles the case when MTL fails to deliver a message. The scenario being, whichever reliable message transport layer or multiple of them below, tries to deliver the message end to end. In case the message does not reach after multiple retries, the error is handed to MDL layer (and yes it is logical). The MDL layer can have a different timeout, choose to deliver the message again or try a differnet mechanism. That is upto the implementor. This prevents the NSI state machine having to deal with message timeouts and retries at the application layer. It simplifies the state machine .

If there is more confusion lets have a skype call.

Inder




On Thu, Dec 6, 2012 at 2:57 AM, Jeroen van der Ham <vdham at uva.nl> wrote:

Hi,
>
>I don't understand this still. What does this add to the current mechanism of reliable message transport and the state machine which handles the error conditions?
>
>Jeroen.
>
>
>On 6 Dec 2012, at 11:43, Guy Roberts <Guy.Roberts at dante.net> wrote:
>
>> Jeroen,
>>
>> The MTL layer looks after delivery between a pair of peering RA and PA.  My understanding is that the MDL has different role, to confirm the correct delivery to all child PAs. This allows the logic associated with checking that all child PAs have responded correctly to be removed from the state machines.  See the attached slide.
>>
>> Guy
>>
>> -----Original Message-----
>> From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf Of Jeroen van der Ham
>> Sent: 06 December 2012 10:18
>> To: NSI Working Group
>> Subject: [Nsi-wg] Message Delivery Layer
>>
>> Hi all,
>>
>> 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 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.)
>>
>> Jeroen.
>>
>>
>> Begin forwarded message:
>>
>>> From: Jeroen van der Ham <vdham at uva.nl>
>>> Subject: Re: [Nsi-wg] Query request
>>> Date: 2 November 2012 10:20:34 CET
>>> To: Jerry Sobieski <jerry at nordu.net>
>>> Cc: <nsi-wg at ogf.org>
>>>
>>> Hi,
>>>
>>> The NSI has chosen to use SOAP and WSDL as its message transport layer. This is a reasonably standard protocol, with support (more or less) in many different languages. For what we aim to do it is pretty good, and it has proven to work pretty well in the past few demos.
>>>
>>> You're saying that we should not be projecting lower layer issues into the NSI layer. In my opinion this is exactly what has happened already. And it is also exactly the reason that we are having all these issues.
>>>
>>> Reliable message transport layers are readily available off the shelf. TCP makes sure that a packet gets from the source to the destination. On top of that we're using HTTP, which also provides some additional guarantees that the message gets there, including some error codes regarding malformed messages, messages out of order, authentication errors, et cetera.
>>> We've used an additional SOAP layer on top, which provides you with even more guarantees.
>>>
>>> Can someone please explain to me that in this scenario we really need to have separate confirmation messages? And even if we do, why do these messages have to be exchanged in a completely separate TCP-HTTP-SOAP session?
>>>
>>> I understand that we have a state machine, with transition using confirmation messages. But can't we use any of the TCP/HTTP/SOAP status messages to achieve that?
>>>
>>> Jeroen.
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> <MDL.pptx>
>
>
>_______________________________________________
>nsi-wg mailing list
>nsi-wg at ogf.org
>https://www.ogf.org/mailman/listinfo/nsi-wg
>

_______________________________________________
nsi-wg mailing list
nsi-wg at ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20121206/cec76287/attachment.html>