October 2010 - Nsi-wg - lists.ogf.org

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

Picture for timing
by Guy Roberts 01 Oct '10

01 Oct '10

Hi all, I like Aaron's proposal for calculating timings, so I have attempted to draw this out as a timing diagram - see attachment. I have made some changes - 1. I assume that the goal is to provide some guarantee for connection availability at the user's requested start time 2. Similar guarantee for availability up to the users' requested end time 3. I have added a margin as proposed by Jerry. Please take a look at these timing diagrams and let me know if they make sense to you. Guy

1 0