Nsis_Imp February 2005

nsis_imp@informatik.uni-goettingen.de

7 participants
21 discussions

Re: AW: [Nsis_imp] Idea for draft about implementation of a ping client
by Sebastian Willert 14 Feb '05

14 Feb '05

On Mon, 2005-02-14 at 09:20 +0100, Constantin Werner wrote: >Hi Ingo, hi all, > >As far as I have read, all hops add their local time as a timestamp to the >packet. >But you should note that this information does not help very much until all >hops have a synchronized (global) clock running. I'd like to add a passage that states that clients are encouraged to synchronize their local time with one of the established synchronization schemes (at least if there are no local conditions that prevent this). I'd also rather like to have a hires timestamp in the message, at least we will be able to calculate the partial round trip times for each intermediate node. Regards, Sebastian

1 0

RE: Idea for draft about implementation of a ping client
by Ingo Juchem 14 Feb '05

14 Feb '05

Hello Constantin, Xiaoming and list, I think we can help the synchronization problem with the following solution: on the way back from Responder to Initiator, each hop generates another timestamp and substracts the first timestamp from this new value. This is divided by two (because we then have the time for the path to and fro) and this value will be substracted from the next hop on the way back. Is this feasible? T1 T1 T1 T1 T1 +--+ +--+ +--+ +--+ +--+ |I |>>|1 |>>|2 |>>|3 |>> ...>>|R | +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ |I |<<|1 |<<|2 |<<|3 |<< ...<<|R | +--+ +--+ +--+ +--+ +--+ T2 T2 T2 T2 T2 so T0 for each hop would be (T2-T1) / 2 and T0 for hop N would be ((T2-T1)/2 ) - (T0 of hop N+1) This is still not perfect however but with regards to the simplicity of the Client it should do. S Ingo

1 0

Re: AW: [Nsis_imp] Idea for draft about implementation of a ping client
by Xiaoming Fu 14 Feb '05

14 Feb '05

i think internet time is an alternative Constantin Werner wrote: > Hi Ingo, hi all, > > As far as I have read, all hops add their local time as a timestamp to the > packet. > But you should note that this information does not help very much until all > hops have a synchronized (global) clock running. > > Br, > Constantin > > > >>-----Ursprüngliche Nachricht----- >>Von: nsis_imp-bounces(a)informatik.uni-goettingen.de >>[mailto:nsis_imp-bounces@informatik.uni-goettingen.de] Im >>Auftrag von Ingo Juchem >>Gesendet: Sonntag, 13. Februar 2005 22:32 >>An: nsis_imp(a)informatik.uni-goettingen.de >>Betreff: [Nsis_imp] Idea for draft about implementation of a >>ping client >> >>Hallo all, >> >>I was thinking of an idea how to test the cleo-projects' >>implementation of GIMPS and as Bernd asked for a ping client.... >>Attached you see an alpha version of the draft (which is my >>first one,btw and wouldn't have been possible without >>Xiaomings and Sebastians help so please bare with me). >> >>Any comments and suggestions are highly appreciated! Please >>criticise as much as possible ;P >> >>However, there are several points that need to be addressed: >> >>1. This draft will not be published without your approval. At >>the moment there only exists an intention to publish it. >>2. This idea needs support through an implementation of the >>Ping Client so we need to confirm somebody does that (Bernd, >>Sebastian, me?) 3. Maybe this rather simple approach does not >>fulfill cleos requirement of a diagnostic tool, so if it's >>not useful we can just drop it 4. Is this a good way for >>testing after all? Is it really needed at all? >>What could be added? > > > _______________________________________________ > Nsis_imp mailing list > Nsis_imp(a)informatik.uni-goettingen.de > http://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp

1 0

[Fwd: Idea for draft about implementation of a ping client]
by Xiaoming Fu 14 Feb '05

14 Feb '05

-------- Original Message -------- Subject: Idea for draft about implementation of a ping client Date: Sun, 13 Feb 2005 22:31:34 +0100 From: Ingo Juchem <ijuchem(a)cs.uni-goettingen.de> To: nsis_imp(a)informatik.uni-goettingen.de CC: Xiaoming Fu <fu(a)cs.uni-goettingen.de> Hallo all, I was thinking of an idea how to test the cleo-projects' implementation of GIMPS and as Bernd asked for a ping client.... Attached you see an alpha version of the draft (which is my first one,btw and wouldn't have been possible without Xiaomings and Sebastians help so please bare with me). Any comments and suggestions are highly appreciated! Please criticise as much as possible ;P However, there are several points that need to be addressed: 1. This draft will not be published without your approval. At the moment there only exists an intention to publish it. 2. This idea needs support through an implementation of the Ping Client so we need to confirm somebody does that (Bernd, Sebastian, me?) 3. Maybe this rather simple approach does not fulfill cleos requirement of a diagnostic tool, so if it's not useful we can just drop it 4. Is this a good way for testing after all? Is it really needed at all? What could be added? So please feel free to add anything you might think could be useful! Regards, Ingo

1 0

Re: [Fwd: Re: [Nsis_imp] a paper on thread-programming v.s. event-loop]
by Tseno Tsenov 13 Feb '05

13 Feb '05

Hi Elwyn, I was not subscribed for NSIS_IMP mailing list. I have just done it. Xiaoming forwarded to me your discussion and I have some questions. Please see inline. ( i kept only the relevant topics) >At 13:14 09/02/2005, you wrote: >Hi Elwyn >I'm just trying to ask you a few question about the red comment: > >1. I think use of cookie (i.e., 3-way handshake) is orthogonal to >piggyingback NSLP in Query. I believe the spec must say piggyback in query >is only used when no cookie is used. >That could well be a better idea... as defined at present *every* query has >a Query-Cookie even if MRS state is not being installed, and one can >piggyback on any Dmode setup message - as you say they are orthogonal. I >think the whole issue of distinction between MRS to be installed and MRS >not to be installed is very unclear... Tseno's FSM diagrams come up with a >different idea from the one i deduced from the text. What do you mean by "MRS state is not being installed"? I think that a MRS state installation follows every successful QUERY/RESPONSE/(possible)CONFIRM message exchange? >There is also this >major problem with policy conflicts between nodes... if some nodes won't do >anything that might affect state (like sending things to the NSLP) before >confirm, but others will, how is the NSLPdata to be handled? when is it to >be transmitted? Greetings, Tseno_

1 0

[Fwd: RE: AW: AW: [Nsis-imp] Call for GIMPS testing at 62nd IETF]
by Xiaoming Fu 10 Feb '05

10 Feb '05

fyi. BTW - please note, nsis-imp(a)ietf.org is an official list of IETF, unlike our private list here. Check before you send a mail to avoid wrong recipient! -------- Original Message -------- Subject: RE: AW: AW: [Nsis-imp] Call for GIMPS testing at 62nd IETF Date: Thu, 10 Feb 2005 12:01:57 -0000 From: Hancock, Robert <robert.hancock(a)roke.co.uk> To: 'Martin Stiemerling' <stiemerling(a)netlab.nec.de>, Tschofenig Hannes <hannes.tschofenig(a)siemens.com>, nsis-imp(a)ietf.org hi, we would be interested in exchanging packets at #62. (of course, we will have to decide whether it's against the -04 version or the -05 version, which doesn't quite exist yet. the former is more likely.) as an aside, we also developed our own state machines to accompany the implementation (and also to help me think about the spec.) while we tried to follow the style/notation of the Fu documents, the actual structure we have ended up with is quite different. we'll try to publish the state machine results before minneapolis, although whether they will make it into any I-D is less clear. robert h. > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: 09 February 2005 19:49 > To: Tschofenig Hannes; nsis-imp(a)ietf.org > Subject: Re: AW: AW: [Nsis-imp] Call for GIMPS testing at 62nd IETF > > > > > --On Mittwoch, 9. Februar 2005 19:55 Uhr +0100 Tschofenig Hannes > <hannes.tschofenig(a)siemens.com> wrote: > > | hi martin, > | > | interesting view. when we worked on eap and eap methods > | implementations the existence of state machine helped us a lot to > | produce interoperable code in a very short amount of time. > | > | i think that this would be helpful for nsis as well if we work on a > | state maschine which allows people to interoperable implement nsis > | quickly. > > True, but it is helpful to start developing your own state > machine first. This covers up ambiguities in the spec better, > since you can compare how people interpret the same text in > different ways and so refine the text plus eliminate the ambiguities. > > Martin > > > > > _______________________________________________ > NSIS-imp mailing list > NSIS-imp(a)lists.ietf.org > https://www1.ietf.org/mailman/listinfo/nsis-imp > _______________________________________________ NSIS-imp mailing list NSIS-imp(a)lists.ietf.org https://www1.ietf.org/mailman/listinfo/nsis-imp

1 0

a paper on thread-programming v.s. event-loop
by Xiaoming Fu 09 Feb '05

09 Feb '05

http://www.eecg.toronto.edu/~ashvin/courses/ece1746-2003/reading/capriccio-…

1 0

New version of FSM design document (003)
by Elwyn davies 09 Feb '05

09 Feb '05

Hi. Please find attached a new version of the FSM design document. Sorry this has taken so long. working out what is actually defined and what still needs work in the specification is not very easy! You will find in this document that there is a lot of red and purple coloured text. these areas are not well defined in the specification (IMO) or need further discussion. Comments from anybody much appreciated.. I will be sending message to the main NSIS list in due course to flag some of the problems and I hope to work with Tseno on the next version of FSM draft. There is still work to be done on the intermediate node FSM but this is essentially a combination of the first and last with some extra work to check that there *is* a next node. Bernd: I'll be in touch to talk about this tomorrow. Regards, Elwyn

1 0

[Fwd: Re: question about NSIS implementation]
by Xiaoming Fu 08 Feb '05

08 Feb '05

fyi -------- Original Message -------- Subject: Re: question about NSIS implementation Date: Tue, 8 Feb 2005 17:28:18 +0100 From: Georgios Karagiannis <karagian(a)cs.utwente.nl> To: Xiaoming Fu <fu(a)cs.uni-goettingen.de> References: <00ae01c50dca$62814100$4c0d5982(a)dynamic.ewi.utwente.nl> <4208E1EF.4080005(a)cs.uni-goettingen.de> Hi Xiaoming Not at this IETF. Two M.Sc. students of mine are working on this (GIMPS and RMD/QoS-NSLP), but we are not yet so far! Best regards, Georgios ----- Original Message ----- From: "Xiaoming Fu" <fu(a)cs.uni-goettingen.de> To: "Georgios Karagiannis" <karagian(a)cs.utwente.nl> Cc: "Xiaoming Fu" <fu(a)informatik.uni-goettingen.de> Sent: Tuesday, February 08, 2005 4:59 PM Subject: Re: question about NSIS implementation > Hi Georgios, > > We are trying for both IPv4 and IPv6 (in some cases IPv4 only, or IPv6 > only, as a first step). Are you going to present it (possibly interop) > in IETF#62? > > Cheers, > Xiaoming > > Georgios Karagiannis wrote: > > Hi Xiaoming > > > > How are you? > > Regarding the implementation of the NSIS protocol stack, are you using IPv4 or IPv6? > > We are using IPv4. > > > > Best regards, > > Georgios > > >

1 0

[Fwd: [Nsis-imp] Call for GIMPS testing at 62nd IETF]
by Xiaoming Fu 08 Feb '05

08 Feb '05

-------- Original Message -------- Subject: [Nsis-imp] Call for GIMPS testing at 62nd IETF Date: Tue, 08 Feb 2005 16:18:56 +0100 From: Martin Stiemerling <stiemerling(a)netlab.nec.de> To: nsis-imp(a)ietf.org Dear NSIS Implementors, I'm currently working on a GIMPS implementation and I'm probably ready to send some GIMPS packets out of my implementations at the next IETF in Minneapolis. Anybody interested in doing a little bit of testing? With best regards, Martin Stiemerling NEC Europe Ltd. -- Network Laboratories stiemerling(a)netlab.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg WWW: http://www.netlab.nec.de _______________________________________________ NSIS-imp mailing list NSIS-imp(a)lists.ietf.org https://www1.ietf.org/mailman/listinfo/nsis-imp

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nsis_Imp February 2005