[Nsi-wg] Notification queries.

[Jerry Sobieski]

A couple comments -

IMO, we need to review in V3 how the messaging is actually 
transported.   I still believe we want a separate transport layer that 
is independent of the NSI messaging itself. i.e. anything that is 
dependent upon WS (or any other transport issues) is moved into the 
lower layer.    The outbound NSI messages are essentially queued by dest 
NSA until a session is established between the source and destination 
NSAs, and then all queued messages can be transported and acked and 
queued at the destination NSA.   If the session is not established, the 
messages will timeout and the sender is notified. This allows either 
side to establish the transport session, and provides the NSI protocol 
layer with some basic messaging primitives for sending or canceling 
messages.   And this basic messaging dialogue is independent of the 
underlying transport mechanism - allowing WS, restful, or other processes.

This still requires two NSAs to configure their respective control plane 
endpoints in order to talk, but this needs to be done anyway bilateraly 
(like we do BGP peers at Layer3) or via a topology announcement.   This 
makes the NSI interface to the lower MTL a fixed and transport 
independent interface.  This MTL interface is internal to an 
implementation, but by defining the MTL interface very succinctly it 
proscibes what is an NSI issue, and what is an MTL issue.  This allows 
us to work on NSI protocol without worrying about things like NATs, FWs, 
or any other aspect that may systemically or transiently prevent a 
message from being transfered immediately.   These are addressed in the 
MTL.   The NSAs simply talk between NSAs.

And further, it removes the requirement that all NSI primitives must use 
the request/response model for all primitives. We need the ability for 
third party agents to interact with the tree, and we will (IMO) need the 
ability for messages to transit "up and over" in the tree to flood 
appropriate notifications if we are serious about end to end cognizance 
of the state of a connection.    In the long run, the NSI protocol will 
be simpler and more flexible if the NSI protocol is treated as an 
asynchronous or symmetric protocol that allows NSAs to send messages 
either direction in the service tree whenever it needs to.  And we move 
the details of the TCP and IP layers down into an independent layer and 
deal with those there.

Interestingly, I don't think specifying such an internal model for NSI 
messaging precludes what we do now, it simply defines clearly which 
layers are responsible for which issues.

...IMO... :-)

For V2, I suggest we keep as discussed in the Maastricht session and get 
the V2 document completed.

My .02 USD.
Jerry


On 6/10/13 10:24 AM, John MacAuley wrote:
> We needed you in Maastricht - you could have shot the bows with us and worked everything out before the NSI meetings on Friday :-)
>
> We had a good discussion in the Friday meeting, and Jerry made a very good point that helped seal the deal.  The argument went as follows:
>
> 1. If we make the assumption that the majority of time there will be no error notifications against a reservation, then whether we use a notificationId or list of error notifications is moot.
>
> 2. When things go bad, they will typically go really bad and probably for more than one reservation.  Having a separate queryNotification() API would allow controlled retrieval of these notifications, and allow those clients not interested in the errors to ignore them.
>
> As for the TCP overhead - all the HTTP client kits these days come with connection pooling by default, so you will already have multiple HTTP connections open to the NSA in question for sending in parallel and reducing the TCP setup overhead.  If you are not using one of these HTTP kits may I recommend picking up one since it makes life a lot easier.
>
> John
>
> On 2013-06-10, at 6:11 AM, Henrik Thostrup Jensen <htj at nordu.net> wrote:
>
>> On Wed, 5 Jun 2013, John MacAuley wrote:
>>
>>> I have attached a discussion document that presents the two original concepts discussed on the NSI call and an optimization to each.
>> I read: Why notifications combined with RPC as a base abstraction is a bad idea :-)
>>
>>> I wanted to make sure I captured both so people do not think one was ignored.  I believe the solution I have recommended (with hallway agreement from Chin and Tomohiro) it the best short term option.  I will have the completed WSDL ready to go so it can be committed upon agreement this week.
>> Are there really going to be some many notifications that anything else than #1a is worth it?
>>
>> Doing a querySummary to check if there are any new notifications, and doing a subsequent queryNotificationSync is WAY more expensive than including all the notifications in the query summary due to the overhead of establishing a TCP+TLS connections[1] which is 6 round trips in total. I can send an awful lot of notifications in that time. With our current scheme, adding a primitive for this is by far the most expensive solution.
>>
>> 1. TCP is 3 messages/3 roundtrips to set up a connection, where the last message/roundtrip can include data. TLS is 12 messages/4 roundtrips, where the first one can be included in the initial TCP data message. Totally we are looking at 15 messages and 6 round trips.
>>
>>
>>     Best regards, Henrik
>>
>> Henrik Thostrup Jensen <htj at nordu.net>
>> Software Developer, NORDUnet
>>
>> _______________________________________________
>> 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