- Nsi-wg - lists.ogf.org

Fwd: WiFi @CERN
by Harold Teunissen 07 Oct '10

07 Oct '10

Folks, It seems that you need to preregister your WiFi device before getting access at the CERN network next week. Use this link https://network.cern.ch/sc/fcgi/sc.fcgi?Action=VisitorRegistration to perform the registration. You also need the name of your LHCOPN conact person. Cheers, Harold Sent from my iPad

1 0

connection timing issues
by John Vollbrecht 07 Oct '10

07 Oct '10

Attached is a revised description of connection timing issues. This is revised from the set of issues I sent out yesterday, which includes changes from our discussion today. I include changes suggested by Tomohiro, Radek, Jerry and Inder. I hope this can help move discussion forward. The issue of whether there needs to be a notify when a connection is established seems to me to be orthogonal to the other issues, but may not be. If there is reason for it to be included in the timing issues described in the first sections of this paper. If so, I am hoping someone can make that case explicitly. John

1 0

time issue
by John Vollbrecht 06 Oct '10

06 Oct '10

Hello all - Jerry and I had a discussion last week about the time issue. I think we developed a useful approach. The idea is to define two times, which I think we all agree exist. 1) available time - time a connection is available to the application to communicate between devices 2) resource time - time a resource is reserved to support available time To further define these - Available time - requested by the user for its application - provided by the network. resource time - time a resource is allocated to a connection - includes setup and teardown time, if any - is time in reservation calendar for resource Available time requested cannot be provided exactly by network because it cannot predict exactly length of setup and take down. I believe we all agree with this. Therefore provided available time can at best approximate requested available time. We agreed that when a user requests automatic start connection it would request available time and the provider would schedule resource time to get as close as possible. When a request is for user initiated connection the time would be for reserved time, and the user initiation can start anytime after the reserved time. Available time depends on setup and take down times of equipment. ----------------- I think we agreed on the above definitions. The definition of time seem useful in discussing what goes in connection service messages. We also talked about some possible implications of this. The difference between available and resource time is setup and takedown time. While it is impossible to be sure exactly how long they will be, it may be possible to define something statistical. For example setup takes an average of 17 sec with std deviation of N. If this is can be defined for the resource, then one can make a prediction about when a connection will be available with a degree of confidence. For example this would allow one to request an automatic connection, for example, at 5pm and have it available 99% of the time. If the average setup time is 17 seconds and I add 10 seconds to be 99% sure, then the service would initiate the connection at 5:00:00 - 0:00:25, or 4:59:35. We talked about including this "setup requirement" in the connection service definition of and NSA, and by implication including this in requests and replies. I think this is worth talking about in the group. John

11 48

minutes from today's NSI call
by Guy Roberts 06 Oct '10

06 Oct '10

... are available here: http://forge.gridforum.org/sf/go/doc16070?nav=1 Guy

1 0

timing diagram
by Guy Roberts 06 Oct '10

06 Oct '10

... attached diagram for connection service automatic timing

1 0

tomorrow's NSI conf call
by Guy Roberts 06 Oct '10

06 Oct '10

Hi all, The following is dial-in information for Wednesday's NSI call: Time: 7:30 PDT 10:30 EDT, 15:30 BST, 16:30 CEST, 23:30 JST Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180 Agenda: 1. NSI Framework document has completed 30 day public comment period, comments need to be incorporated and document released. https://forge.gridforum.org/sf/go/artf6449?nav=1 2. Review the ongoing discussion on the timing of the connection service: http://forge.gridforum.org/sf/go/doc16067?nav=1 Guy

3 3

Timing issues
by Jerry Sobieski 05 Oct '10

05 Oct '10

Hi all- In an effort to try to find clarity and concensus on these time issues, I put a few slides together that I hope will differentiate terminology and purpose. And I hope this will make clearer some issues that we feel good about but that are not sufficiently resolved (IMO) for a standards document. First - I think there are two aspects of "time" we are concerned about - Calendar Time or absolute time, and Protocol Timing or relative time. The former is something that I believe NTP will handle adequately for us - and in the background - but we do need to probably state some specific for how synchronized around a common time the NSAs need to be, and we should clearly state *why* we think it is necessary. Second, IMO, I believe we need to understand better the "protocol timing" issues and why we need to do more work on this. Its not solved by NTP. I use the auto-provisioning scenario to illustrate the various possible timing implications that can crop up from the way we have been leaning in the discussions. So please look over the slides...I can explain in more detail if someone want to offline, or I can summarize them during the call on Wed. I hope this helps... Jerry

1 0

Face to face NSI meeting @ GLIF, Tuesday afternoon Oct 12, 3 - 6 pm
by Inder Monga 05 Oct '10

05 Oct '10

It seems a few of the NSI participants are also attending GLIF week of October 11th. I propose we meet face to face on Tuesday, October 12th afternoon from 3 - 6 pm for face to face protocol discussions, followed by group dinner. Please RSVP to me and let me know if you can make it so I can plan the space and the restaurant. Look forward to meeting many of you at Geneva, Inder --- Inder Monga ANI Testbed imonga(a)es.net ESnet Blog (510) 499 8065 (c) (510) 486 6531 (o) "Whatever your mind can conceive and believe it can achieve." - Napoleon Hill

4 3

Re: [Nsi-wg] JGN2 status
by John Vollbrecht 04 Oct '10

04 Oct '10

Yes - JGN can be part of GLIF demo. I think we should leave it connecting to StarLight only for GLIF. We can work out whether it goes to MANLAN through ION for after GLIF. Thanks for setting this up Alan. John On Oct 4, 2010, at 6:52 AM, Thomas Tam wrote: > Hi John, > > Would JGN2 be part of the GLIF demo? > > -Thomas > > > On 10-10-04 12:11 AM, "Alan Verlo" <darkman(a)evl.uic.edu> wrote: > > > > CWAVE and PacificWave have now approved a path to connect JGN2 from LA to > StarLight for JGN2 to participate in the demo. JGN2 has also approved > vlans in our 1700-1799 range, so attached is an updated vlan table. > > Alan > > On Thu, 30 Sep 2010, John Vollbrecht wrote: > > > We will have a call tomorrow morning to review status. Call Info > > 9 AM ET - 6PT, 3CET, 10PM JST > > > > > Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) > > > Enter access code: 0170468 > > > > > > tentative agenda -- > > > > Status of connectivity thru GOLEs to iperf Servers > > Thomas has been working on this. A number of servers have been tested, I believe with Pinger. Thomas will update status tomrorrow > > > > Status of connectivity between GOLEs > > Most GOLEs are interconnected. I believe that MANLAN has not been exercised from NetherLight yet. Peter will update connectivity of NetherLight to others. > > Connectivity using USLHCnet is underway. I am not sure of status of this - Azher will update > > > > Status of Fenius and SuperAgent > > Internet2 has installed the superagent and fenius server for MANLAN. This is being setup to have these talk to each other. Kavitha will give status of this work. Evangelos and Kavitha will describe how other fenius servers will connect to the superagent. Evangelos give status of Fenius development. > > > > Status of Fenius > > Each site will update status of their work on fenius. Last I heard no one was quite ready to go. This needs to start testing soon - it is less than two weeks before GLIF meeting. We can discuss contingency plans > > > > Other issues - > > > > state of topology distribution, possible backup topology that assumes static paths if fenius doesn't work at a particular location. > > > > Discussion of demo plans - I think the demo can consist of a set of prescheduled connections, and perhaps a manual connection during the talk. Who should run the demo? Who will be at GLIF? > > > > GLIF presentations - GOLE pilot, gni-api, perfSONAR in sequence > > > > I will put out a proposed pilot framework, gni-api hopefully will include details of superagent and fenius - as well as whatever else, and perfSONAR will include description of details of perfSONAR implementation of pilot, > > > > --- > > > > are there other topics we should cover > > > > John > > > > > > > > >

1 0

Re: [Nsi-wg] clock skews
by Guy Roberts 01 Oct '10

01 Oct '10

Jerry, I have modified the timing diagrams to account for the two possible sources of start-time (a user or the requesterNSA). See attachment. Actually, thinking about this some more I don't think we need to make a distinction about the origin of the start-time timestamp... based on my reasoning below. NTP, if correctly configured, is a protocol for synchronising PCs to a global reference standard (rather than synchronising the clocks between each other). http://en.wikipedia.org/wiki/Network_Time_Protocol So I think we can get around the problem of an unknown originator of the time if we assume (this must be an explicitly stated assumption) that the BOTH the 'user', the 'requesterNSA' and the 'providerNSA' clocks have NTP enabled. If this is true, we don't need to care about the origin of the start-time timestamp and set the value of X (skew) to be 2xNTP accuracy (approx 20ms). Does this make sense to you? Guy From: Guy Roberts Sent: 01 October 2010 14:22 To: 'Jerry Sobieski' Subject: clock skews Jerry, Thinking about the clock skew problem some more - in my diagram where we have put 'skew' this needs to be the skew between the clock of the point where the timestamp for the requested start-time was added and the time of the provider NSA. We can *NOT* assume (as I have done) that the requesterNSA added the start-time. More often than not this is added by hand by a human or forwarded from anther machine.... Guy

1 0