From henk at ripe.net Fri Sep 1 11:58:55 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Fri, 01 Sep 2006 11:58:55 +0200 Subject: [tt-tf] TTM Task Force Message-ID: <7.0.1.0.2.20060901115103.034d17e8@ripe.net> Dear All, At RIPE 52, we voluntered to be members of a task force to study the future of TTM. I planned to start the discussion on this before the summer, but for a variety of reasons this didn't happen. However, we still have time before the RIPE meeting and we should be able to come up with something. In the next week, I'm planning to do the following: 1. Wake y'all up (by sending this mail). 2. Post a short report on our experiences with Luca Deri's prototype implementation of the CBM proposal. 3. Post a write up on the TSC work (as this might be very relevant for a GPS-free TB). 4. Post some notes on our work on the (Gert Doering) Multicast proposal. 5. Post a draft proposal for TTM in the future, as a starting point for our discussion. I'd like to invite you all to comment on these docs, come up with good ideas, throw tomato's in my direction if you disagree, and participate in the discussion as you see fit. We do have a little over a month, this should be sufficient time, but we cannot afford to wait forever to get started, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. From henk at ripe.net Tue Sep 5 16:04:06 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 05 Sep 2006 16:04:06 +0200 Subject: [tt-tf] Re: TTM Task Force In-Reply-To: <7.0.1.0.2.20060901115103.034d17e8@ripe.net> References: <7.0.1.0.2.20060901115103.034d17e8@ripe.net> Message-ID: <7.0.1.0.2.20060905153918.0340d588@ripe.net> Dear All, > 2. Post a short report on our experiences with Luca Deri's prototype > implementation of the CBM proposal. At SANE 2006, Luca showed us a very first prototype of an implementation of the CBM proposal. This was essentially a mock-up of the web front-end with very little else. A month or so later, he sent us a URL (I'm not sure if I can share it, so I don't) of a more functional prototype. This set-up consisted of two elements: a central machine to configure measurements on remote probes and retrieve/show the results. The probes doing the measurements consisted of linux boxes with only the tools installed that one would find on a Linksys or similar device. This was for rapid development. Measurements inclded ping, dns-queries and http queries to websites. The central box took care of authorization. All in all, it looked very nice but one should realize that the most important part (the probe) didn't run on the device it is supposed to be running. Luca's next plan was to port the probe code to embedded devices. This would be done over the summer. Next week, I'll meet Luca in Pisa to see what he (plus students) did over the summer. I'll report on that next later. I'll also ask if the URL can be shared with this group. Cheers, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. From henk at ripe.net Wed Sep 6 13:37:36 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Wed, 06 Sep 2006 13:37:36 +0200 Subject: [tt-tf] Re: TTM Task Force/Multicast In-Reply-To: <7.0.1.0.2.20060901115103.034d17e8@ripe.net> References: <7.0.1.0.2.20060901115103.034d17e8@ripe.net> Message-ID: <7.0.1.0.2.20060906132901.03417af0@ripe.net> Dear All, > 4. Post some notes on our work on the (Gert Doering) Multicast > proposal. We have a student here (Franz) working on the Multicast proposal. He started about 2 months ago and will stay with us until early next year. His assignment is to do a first implementation of the Multicast proposal. So-far, he has written a multicast beacon. This beacon can send (time-stamped) multicast packets around. He also wrote a listener that listens to the traffic. Combining the data gives plots of delays and losses for the combination of sender and known receivers. We can do a "light" version of the software, that is, a version where the sender or receiver doesn't do time-stamping. This can be run on non-TTM boxes but only show loss. This still needs work in the presentation layer, we hope to have that ready by RIPE53. The fun part will come next: combine paths with delay/losses and see if one can pin-point a distribution problem. I'm planning to have Franz do a talk and demo @ RIPE53. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. From henk at ripe.net Fri Sep 8 15:10:45 2006 From: henk at ripe.net (Henk Uijterwaal (RIPE NCC)) Date: Fri, 8 Sep 2006 15:10:45 +0200 (CEST) Subject: [tt-tf] TTM Task Force/TSC clock. Message-ID: Dear All, The third thing I promised for this week... Some years ago, Darryl Veitch at U.Melbourne suggested to use the TSC register found in modern Pentium chips as a reference clock reference. The TSC register is related to the internal clock of the chip and very stable even when the chip is mounted inside a regular PC. Darryl and colleagues published a paper on the principle at IMC. If this works as expected, it will allow for a TTM setup without the need for a local GPS antenna. This will obviously make deployment a lot easier. The setup will require a stratum 1 NTP server a few hops away and there will be some loss of accuracy. All this will have to be quantified and calibrated. Over the last years, we have been trying to us this idea in TTM. Mark Santcroos worked on this while still at the NCC. When he left last year, the system worked but it had to be calibrated. This was to be done by the U.Melbourne. For various reasons, they only started on this in June this year. We now have a setup where the user can switch between standard GPS-based timestamping and TSC-based timestamping. We still have to add a switch and some code to the TTM software to do this for TTM. The idea is to do measurements with this setup in various circumstances, switching back and forth between timekeeping models, and compare the results. First results look good, but a lot of work still has to be done. The goal is to have this ready by RIPE53. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ From henk at ripe.net Fri Sep 22 12:49:42 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Fri, 22 Sep 2006 12:49:42 +0200 Subject: [tt-tf] TTM service 2007-2009 Message-ID: <7.0.1.0.2.20060922124903.0341ea50@ripe.net> Hi all, Please see below. For discussion, Henk - - - - Draft proposal for the TTM service 2007-2009. Services on the boxes: Starting with the current set of boxes and services: * Delay/Loss/Jitter/Traceroute: At RIPE52, there was clear interest in the data. We propose to continue these measurements. The software on the TBs exists as well as the code to analyze it. We do want to make a couple of adjustments * OWAMP will be added as a method to do measurements on demand, either between TB?s or outside the TTM network (subject to access restrictions). * Data will be collected at a central point and initial processing will still be done. However, we will reduce the number of plots and lists produced by default on a daily basis to something like: daily plots, daily overviews, weekly overviews. All other plots will only be generated on demand. This will result in a bit of lag when one asks for a plot. On the other hand, producing a large number of plots that nobody ever looks at is not a good idea either. * Network alarms will be revisited, is anybody ever looking at them? * Data will continue to be visible on the TB itself. * We will set up a DQM mechanism, with a daily routine to look at the data and see if the plots make sense (rather than what we do today: are they being filled). * DNSMON * DNSMON is a valuable service and we will keep it. Features to be added could include: * IPv6 * Trends/Alarms See below. * New: Protocol beacons * The boxes will start to run protocol beacons, i.e. something that sends out packets for a service on a regular basis, allowing people to monitor their systems. * An example is the multicast work. Another example are the debogon prefixes on the RIS. * New: Network experiments. * We will set up ?shell accounts? that will allow interested parties to do one-off network experiments. (Proposal, measurement, analysis, publication). * The TB will just offer the framework for the experiment and a little operator support, whoever proposes the experiment will be responsible for doing the work. * Similar models have been proposed (VINI, PlanetLab, ), we will see what we can copy and where we can collaborate. * This is intended as a community services for R&D that requires access to real hosts in the real Internet. * Example from the past: Kroot anycast measurements. * New: CBM reference point/server: the boxes will be set up such that interested ISPs can use them for this purpose. The box will offer the configuration site, plus a target for the measurements. The NCC will look into aggregation of data, from reports for one user, to a report for one ISP. Ownership of the boxes: * For both TTM and DNSMON, it is essential that there are a large number of active TTM boxes at interesting locations. * For this reason, the NCC proposes to install a number of boxes at important locations for free. The NCC pays for the hardware and service contract, the local site only for power/connectivity/operations (making it essentially free). Rough criteria for hosting a box: * Major AS * Only one box per AS, if a site wants more, they have to pay * Commitment from the site to operate the box for a 3 year period. Selection will be a ?beauty contest?. * Other sites can still order boxes as before, the same goes for AS who want to install more than one box. Hardware: Outdated hardware, hardware without a current contact person, etc, is an ongoing concern for our operations people. We suggest the following changes: * We start writing off the hardware, say 3 or 4 years (perhaps longer for the clocks). After this period, a box will be automatically switched off unless a site buys new hardware. * Current hardware older than 3 years will be phased-out and/or replaced. * We will allow people to build their own box, subject to the restriction that our software will run on it without modifications. This means that FreeBSD should run on the box without modifications. * We will start to support GPS-free boxes (TSC clock) once that technology is mature. A nearby Stratum-1 NTP server may be required. Administrative: Our finance department faces a lot of problems collecting the service fee. It is often not clear to people that the SF is an integral part of the service. Also collecting money from hosts where the contact people have disappeared. We suggest: * The current service contracts will be revisited and replaced (taking into account the text of the current contract) by a new contract. * In the new system, there will be one contract to cover: * Hardware * Service fee for a 3 year period * Shipping, import/export duties, The host has to pay the entire sum at once, in advance. After that, there will be no ?hidden fees?. * HW support for the boxes will cover the lifetime of the boxes. In other words, one knows in advance that the service will be there for 3 years. * The service for sites who have not paid for several years and who we don?t consider interesting will be stopped. * Sites will be asked to provide current contact information and to regularly check this. Lifetime of this proposal: This is a 3-year plan, 2007-2009, to be evaluated afterwards. Operational (for the NCC): * The number of operational problems will be reduced, as the H/W will be newer as well as more uniform. * Contacts for the boxes should be well known again. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. From henk at ripe.net Tue Sep 26 12:11:50 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 26 Sep 2006 12:11:50 +0200 Subject: [tt-tf] Fwd: Re: TTM Service 2007 - 2009 Message-ID: <7.0.1.0.2.20060926121142.035aabd0@ripe.net> >X-Original-To: henk at ripe.net >Delivered-To: henk at ripe.net >Date: Tue, 26 Sep 2006 10:07:18 +0100 >From: Brian Nisbet >User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) >X-Accept-Language: en-us, en >To: Henk Uijterwaal >Subject: Re: TTM Service 2007 - 2009 >X-Enigmail-Version: 0.92.0.0 >X-RIPE-Spam-Level: >X-RIPE-Spam-Tests: BAYES_00 >X-RIPE-Spam-Status: U 0.285436 / -2.6 >X-RIPE-Signature: 20a856a8701b575655ec0799ed4b09ee > >Henk, > >I tried to send this to tt-tf at ripe.net but it was bounced. > > > Please see below. For discussion, > >I don't have a huge amount to add to this as, in general, I >agree with it all, but there are a couple of points I'd like >to note. > > > Draft proposal for the TTM service 2007-2009. > > > > Services on the boxes: > > Starting with the current set of boxes and services: > > * Delay/Loss/Jitter/Traceroute: > > At RIPE52, there was clear interest in the data. We propose to > > continue > > these measurements. The software on the TBs exists as well as the code > > to analyze it. We do want to make a couple of adjustments > > * OWAMP will be added as a method to do measurements on demand, > > either between TB?s or outside the TTM network (subject to access > > restrictions). > >That makes perfect sense and should widen the appeal. > > > * Data will be collected at a central point and initial processing > > will still be done. However, we will reduce the number of plots and > > lists produced by default on a daily basis to something like: daily > > plots, daily overviews, weekly overviews. All other plots will only be > > generated on demand. This will result in a bit of lag when one asks > > for a plot. On the other hand, producing a large number of plots that > > nobody ever looks at is not a good idea either. > >As one of those who pointed out we were still using the data that should >satisfy our needs. We very rarely use the box as an up to the second >resourse, so some delay for a more detailed plot is fine. I would >guess, however I wouldn't want to presume, that other operators act >in similiar ways. > > > * Network alarms will be revisited, is anybody ever looking at > > them? > >I know I haven't looked in quite a while, but as Mike Norris used to >use them a lot I will check with him, however I suspect you are right >that their readership is extremely low. Is the overhead of generation >all that high? > > > * Data will continue to be visible on the TB itself. > > * We will set up a DQM mechanism, with a daily routine to look at > > the data and see if the plots make sense (rather than what we do > > today: are they being filled). > >Both great. > > > * DNSMON > > * DNSMON is a valuable service and we will keep it. Features to > > be added could include: > > * IPv6 > > * Trends/Alarms > >Excellent. > > > See below. > > * New: Protocol beacons > > * The boxes will start to run protocol beacons, i.e. something > > that sends out packets for a service on a regular basis, allowing > > people to monitor their systems. > > * An example is the multicast work. Another example are the > > debogon prefixes on the RIS. > >Ah, this would be excellent and a welcome service, primarily because >it would allow us to maintain one fewer server ourselves and we're >always happy if we can manage that. > > > * New: Network experiments. > > * We will set up ?shell accounts? that will allow interested > > parties to do one-off network experiments. (Proposal, measurement, > > analysis, publication). > >Excellent, assuming the necessary strict controls etc. > > > * New: CBM reference point/server: the boxes will be set up such > > that interested ISPs can use them for this purpose. The box will offer > > the configuration site, plus a target for the measurements. The NCC > > will look into aggregation of data, from reports for one user, to a > > report for one ISP. > >While being broadly in favour of this I still feel we need to be >extremely careful about how and to whom this data will be accessible. >I think it could be an extremely useful resource for all concered, but >also a potential way of making some ISPs (unfairly) angry at RIPE. > > > Ownership of the boxes: > > * For both TTM and DNSMON, it is essential that there are a large > > number of active TTM boxes at interesting locations. > > * For this reason, the NCC proposes to install a number of boxes at > > important locations for free. The NCC pays for the hardware and > > service contract, the local site only for > > power/connectivity/operations (making it essentially free). Rough > > criteria for hosting a box: > >This is a fantastic idea and one that I am very glad to see. > >Roughly how many boxes would be expected to be deployed under this >scheme? > > > Hardware: > > Outdated hardware, hardware without a current contact person, etc, is > > an ongoing concern for our operations people. We suggest the following > > changes: > > * We start writing off the hardware, say 3 or 4 years (perhaps > > longer for the clocks). After this period, a box will be automatically > > switched off unless a site buys new hardware. > >When you say 'new' hardware, are you talking about a new model of the >same box (which may be difficult when it comes to Dell 350s?) or is >the server base for the TTM box being upgraded? And if so, to what? > > > * We will start to support GPS-free boxes (TSC clock) once that > > technology is mature. A nearby Stratum-1 NTP server may be required. > >Considering the problems I'm currently having getting the antenna for >TT-35 to play nice, this is encouraging. I strongly suspect HEAnet >will continue to want a Stratum-1 clock on our box, but anything that >can be done to make installation easier for the majority is a good >thing. > > > Administrative: > > Our finance department faces a lot of problems collecting the service > > fee. It is often not clear to people that the SF is an integral part > > of the service. Also collecting money from hosts where the contact > > people have disappeared. We suggest: > > * The current service contracts will be revisited and replaced > > (taking into account the text of the current contract) by a new > > contract. > > * In the new system, there will be one contract to cover: > > * Hardware > > * Service fee for a 3 year period > > * Shipping, import/export duties, > > The host has to pay the entire sum at once, in advance. After that, > > there will be no ?hidden fees?. > >Ah yes, most useful. Is there any fear that a higher price will put >people off? > > > * Sites will be asked to provide current contact information and to > > regularly check this. > >Is the intention for the site to check this or for the RIPE NCC to >prompt the site to check this? > > > Lifetime of this proposal: > > This is a 3-year plan, 2007-2009, to be evaluated afterwards. > >Overally I think this is an excellent plan and, on what is given >here, I believe it will maintain those parts of the service that >Gert and I were so forthright about in Istanbul while providing >a model to stabilise and then expand the network. > >Thanks, > >Brian. > >-- >Brian Nisbet, >Senior Network Engineer, HEAnet >Email: brian.nisbet at heanet.ie >Tel: +35316609040/Fax:+35316603666 ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. From henk at ripe.net Tue Sep 26 13:05:07 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 26 Sep 2006 13:05:07 +0200 Subject: [tt-tf] Re: TTM Service 2007 - 2009 In-Reply-To: <4518EDC6.9030804@heanet.ie> References: <4518EDC6.9030804@heanet.ie> Message-ID: <7.0.1.0.2.20060926125401.03645a00@ripe.net> Brian, >I tried to send this to tt-tf at ripe.net but it was bounced. Forwarded it. > > Hardware: > > Outdated hardware, hardware without a current contact person, etc, is > > an ongoing concern for our operations people. We suggest the following > > changes: > > * We start writing off the hardware, say 3 or 4 years (perhaps > > longer for the clocks). After this period, a box will be automatically > > switched off unless a site buys new hardware. > >When you say 'new' hardware, are you talking about a new model of the >same box (which may be difficult when it comes to Dell 350s?) or is >the server base for the TTM box being upgraded? And if so, to what? Replace by something that is available then and is suitable to run the TTM software. At the moment, that would be a Dell 850, but I'm certain that in a couple of years, it will be something different. > > The host has to pay the entire sum at once, in advance. After that, > > there will be no "hidden fees". > >Ah yes, most useful. Is there any fear that a higher price will put >people off? I thought of that and this is a possibility. OTOH, it now takes a lot of time/money from our side to collect the service fees and some sites get the service for "free" (by not paying). I don't think that is good either. I personally prefer to have a smaller number of sites that all pay, over a large number of sites where only a fraction pays. > > * Sites will be asked to provide current contact information and to > > regularly check this. > >Is the intention for the site to check this or for the RIPE NCC to >prompt the site to check this? I think prompting is the best way. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000.