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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg