[Nsi-wg] Message Delivery Layer

[Inder Monga]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20121206/9a226097/attachment-0001.html>