[Nsi-wg] Notification queries.

[John MacAuley]

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