- Tt-tf - mailman.ripe.net

List to be closed
by Henk Uijterwaal 07 Dec '07

07 Dec '07

Dear All, As you have probably seen on the TT-WG list, there were no further comments on the NCC proposal for the TTM future. As this concludes the work of the TT-TF, the mailing list tt-tf(a)ripe.net will be closed early next week and the TF will be disbanded. The archives (http://www.ripe.net/maillists/ncc-archives/tt-tf/) will remain online though. If there is anything further to be discussed, we can use the regular tt-wg(a)ripe.net mailing list. I'd like to thank everybody for his contributions to the TT-TF. Kind regards, 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 ------------------------------------------------------------------------------ Is one of the choices leaving the office open? Alan Greenspan on the next elections

1 0

Re: [tt-tf] TTM futures - final proposal
by Mark Dranse 29 Oct '07

29 Oct '07

Hi Simon, Thanks for taking the time to comment. On 27/10/2007 14:23, Simon Leinen wrote: > Sorry for the late followup. > > Mark Dranse writes: >> 3. To further expand the network in the areas where support and >> technical expertise are limited (e.g. small/residential customers), >> a probe itself should be as lightweight as possible (no GPS, >> embedded systems). The CBM proposal fits well in this category. This >> setup doesn't allow one-way measurements, although an aggregated >> view from a cluster of such lightweight probes can enhance the TTM >> and add-on services. > > "This setup doesn't allow one-way measurements" seems too strong. > Synchronized clocks are needed for precise one-way delay measurements, > but you could still perform precise (and useful) one-way loss and > delay variation measurements. By way of clarity, what is meant here is that the CBM nodes will not ever be included in the full global TTM mesh to participate in the very precise GPS synchronised one-way measurements as we currently know them. Of course, CBM nodes can do simpler and less precise one way measurements between themselves and their parent TTM node. The original CBM proposal can be found here by way of reference: http://www.ripe.net/ripe/maillists/archives/tt-wg/2005/pdf00001.pdf Kind regards Mark -- Mark Dranse RIPE NCC

1 0

Re: [tt-tf] TTM futures - final proposal
by Mark Dranse 18 Oct '07

18 Oct '07

Hi Brian, Thanks for your kind comments. I'll respond to your specific questions: On 18/10/2007 16:24, Brian Nisbet wrote: [...] > This is excellent and I'm very happy to see a support and upgrade path > proposed. I think that the two options should suit the various TTM > sites. So, those questions I mentioned... > > I assume that current sites that have been in place for over > three years will be able to avail of new hardware immediately upon > signing a new contract (and, of course, dependent on the new hardware > being available)? Yes, absolutely. We are committed to ensuring a proper phased transition for existing hosts. Obviously, we will all need to be realistic about this - we can't do 70 in one day. > Will all TTM sites be asked to sign a new contract when this plan > comes into effect, regardless of age of hardware? No. Anyone with hardware less than 3 (or 5) years old should carry on regardless, although of course, you might like to take advantage of the new attractive pricing to locate an additional TTM somewhere in your network... > Will the hardware still be adminable only by the NCC? Yes - 100%, this will not change. Regards Mark -- Mark Dranse Information Services Manager RIPE NCC

1 0

TTM futures - final proposal
by Mark Dranse 18 Oct '07

18 Oct '07

Dear Task Force, Based on feedback previously provided, below you will find the final outline of our plans for future direction of the TTM network. We appreciate you taking the time to contribute to this, and encourage any final comments either before or during our meeting next week. Key elements of this plan, including some implementation details and interface mockups, will be presented during the TT-WG on Thursday 25th October during RIPE55. Vision ~~~~~~ Our goal is to expand and maintain the TTM network, increasing the value of the service to the community at large and to the owners of the probes. This will be achieved by making improvements in the following areas: - Enhancing the measurement architecture - Enhancing the TTM network architecture - Improving alarms and reporting - Improving the business model These changes will require a radical rethink in probe and measurement architecture, resulting in new structures for the probes themselves, and the tests they carry out. TTM network infrastructure ~~~~~~~~~~~~~~~~~~~~~~~~~~ The TTM network is the foundation of the TTM and associated services. Therefore, these services strongly depend on reliability and coverage of the network. In particular it is essential that there are many active probes at interesting locations, that probes are well maintained, and that coverage can be further increased by deploying simpler devices. Let's consider these goals separately. 1. For the services that the TTM provides, it is essential that there are enough active probes at interesting locations. At present, we are relatively limited by the availability, and geography,of those willing to sponsor probes, and as a result, some rather dense and unhelpful clustering has occurred. A possible solution to mitigate this problem is to install a number of probes at important locations for free. The NCC will fund the hardware and service contract, while the host will support the probe with power, connectivity and remote-hands. Rough criteria for hosting a box: - Major AS or IX - Only one free box per AS – if a site wants more, they have to pay - Commitment from the site to operate the box for a minimum 3 year period - Selection will be a “beauty contest”, and at the discretion of the NCC 2. However this alone will not ensure sustained growth of the network. This needs to be addressed by increasing the number of sponsored probes and ensuring that those probes are well maintained and upgraded when necessary. Therefore It is important to make the TTM services attractive to sponsors of the TTM probes to increase stability and steady growth of the network. Several incentives can be provided: - Allow the sponsor to define their own measurement mesh and specific routine measurements (level of detail and frequency). Management of gathered data will be the responsibility of the sponsor. - Support the sponsor in creating dynamic meshes to monitor their own applications and services, providing a global picture of availability. These enhancements will operate in unison with the existing full-meshed measurements which we are committed to supporting on an ongoing basis. 3. To further expand the network in the areas where support and technical expertise are limited (e.g. small/residential customers), a probe itself should be as lightweight as possible (no GPS, embedded systems). The CBM proposal fits well in this category. This setup doesn't allow one-way measurements, although an aggregated view from a cluster of such lightweight probes can enhance the TTM and add-on services. TTM Measurements ~~~~~~~~~~~~~~~~ 1. Near real-time measurement of application services The TTM network will continue to act as a measurement platform for critical Internet public service and infrastracture applications (e.g. root and ccTLD DNS monitoring and of multicast performance). These independent tests are of benefit to the service administrators, the end users, and to the hosts of TTM probes. We will improve this service by - Considering measuring new applications as the need arises - Making reporting clearer (see below) - Enhancing alarm functionality (see below) - Implementing the CBM proposal (see infrastructure section) 2. Global one-way measurement platform The TTM network will continue its one-way measurements of the delay/jitter/loss between the distributed probes. These independent tests are of benefit to the hosts of the TTM probes, to the broader community, and to specific interested organisations who rely on neutral views (e.g. regulators and governments). We will improve this service by - Introducing custom measurement meshes (see infrastructure section) - Introducing support for OWAMP. This will allow the TTM network to interact with other compatible networks, and will facilitate measurements on demand (subject to access restrictions) - Setting up data quality checks to ensure the sanity of presented data - Making reporting clearer (see below) - Enhancing alarm functionality (see below) 3. General purpose distributed measurement platform for ad-hoc experiments The TTM network will be developed to enable interested parties (e.g. CAIDA) to conduct a variety of time-limited, global, local, or mid-range experiments (for example the k-root anycast studies). An outcome will typically be an analytical report that will be open to the community. In addition to this, the NCC will provide various ad-hoc modules which all test box hosts may use to carry out bespoke tests of interest to them - the initial implementation of this will cover private application testing. Reporting ~~~~~~~~~ We consider the current reports to be complex and overwhelming. We will simplify the presentation of results to include fewer pre-generated plots, and shift our focus to the identification of trends and changes in gathered data. We will continue to support tools to generate plots on demand, and raw data will continue to be available for analysis. DQM will be used to verify data sanity. In addition to this, we are investigating ways to merge TTM data with that from other services - such as RIS - combining data from these powerful platforms to display broader and more representative pictures of Internet behaviour in near real-time. Alarms ~~~~~~ We consider the current alarm functionality to be complex and overwhelming. This will be re-engineered to provide more powerful network and application alarms. We will enable users to run a variety of NCC defined tests, limited by number, frequency and longevity, so as to ensure that these tests do not impact public TTM network operation. As with reporting, we will simplify presentation of generated alarms to make them clearer. Admin and pricing model ~~~~~~~~~~~~~~~~~~~~~~~ As a result of feedback from existing TTM hosts, and others interested in participating, we intend to move to a three year model with two payment options and the possibility to extend by up to two years. Option 1 will be three recurring annual payments of €1800, which will include all hardward, setup and service costs. Option 2 will be one single up front payment of €5000, which will include all hardware, setup and service fees for three years, and includes an advance payment discount. Towards the end of year three, hosts will be given the opportunity to extend their service contract by up to two years at the prevailing annual fee at that time (currently €1000). Hosts extending for just 1 year will be given the option to extend for one further year. All contracts will expire after five years. We recommend entering into a new contract with new hardware at this point. However, if your hardware continues to function reliably, you may opt to participate without a contract. In such cases you will no longer receive software updates, general support, or access to some advanced features of your testbox software. We appreciate the time and effort expended by existing hosts and will obviously ensure a fair and favourable transition for all. -- Mark Dranse Information Services Manager RIPE NCC

1 0

TTM - pricing proposal
by Mark Dranse 15 Oct '07

15 Oct '07

Dear Colleagues, At RIPE 54 in Tallinn, we discussed new pricing models for TTM participation. The outcome of those, and other discussions, is as follows. We believe that TTM hardware has a five year lifespan (beyond this its reliability cannot be guaranteed). However, five years is a very long commitment for many organisations. We therefore propose a three year charging model/contract, with a possible two year extension. We propose that this be implemented in the two variations outlined below: 1) Three recurring annual payments of €1800, which will include all hardware, setup and service costs. 2) One single up front payment of €5000, which will include all hardware, setup and service fees for three years. This includes a discount for paying up front. Towards the end of year three, hosts will be given the opportunity to purchase up to two years additional service at the prevailing rate at that time. This is currently €1000pa. All contracts will expire after five years. We recommend entering into a new contract with new hardware at this point. However, if your hardware continues to function reliably, you may opt to participate without a contract. In such cases you will no longer receive software updates or general support. We will ensure that existing test box hosts are treated fairly and favourably during their transition from the old to the new model. We invite any general feedback on this proposal, either on this mailing list or at the Test Traffic Working Group session during RIPE 55. Regards Mark Dranse, Information Services Manager, RIPE NCC

1 0

TTM Futures update
by Mark Dranse 15 Oct '07

15 Oct '07

Dear colleagues, We would like to take this opportunity to thank all those who have participated in this task force, either in person at the Test Traffic Working Group (TT WG) sessions, publically via this list, or by way of private comments. Those of you present in Tallin last May will remember the presentation on our draft proposal: http://www.ripe.net/ripe/meetings/ripe-54/presentations/TTM_Future.pdf We have now incorporated your feedback into a final proposal that will be presented in the TT WG at RIPE 55 in Amsterdam next week. This will include: - In-depth implementation details for new alarms and ad-hoc testing architecture - Details of work we have completed on improving data presentation We will also discuss the new pricing structure proposal that has been developed as a result of direct user feedback. To stimulate discussion on this, advance details will be sent to this list later today. We look forward to seeing you next week at the TT WG during RIPE 55. Regards Mark Dranse, Information Services Manager, RIPE NCC

1 0

Fw: NCC#2007051343 de.cix subscribe
by RIPE NCC Hostmaster 14 May '07

14 May '07

Hi, Arnold Nipper of de.cix wants to be subscribed. Thanks Scott Donald RIPE NCC IPRA ----- Begin forwarded message ----- Date: Mon, 14 May 2007 11:25:36 +0200 From: Arnold Nipper <arnold.nipper(a)de-cix.net> To: RIPE NCC Hostmaster <hostmaster(a)ripe.net> Subject: Re: NCC#2007051343 de.cix subscribe tt-tf(a)ripe.net Cc: Arnold Nipper <arnold.nipper(a)de-cix.net> Message-Id: <46482B10.7020709(a)de-cix.net> On 14.05.2007 10:57 RIPE NCC Hostmaster wrote > Dear Arnold, > > I don't understand what "de.cix subscribe tt-tf(a)ripe.net" means. > > Please explain so we can help you. > de.cix is my NCC-RegID. You asked me for that During RIPE54 a new Task Force was created. To join this task force one should send an email to tt-tf(a)ripe.net. That's what I did by saying "subscribe tt-tf(a)ripe.net". Please ask Daniel Karrenberg for details on tt-tf. HTH, Arnold -- Arnold Nipper e-mail: arnold.nipper(a)de-cix.net DE-CIX Management GmbH phone/mob: +49 172 265 0958 Lichtstr.43i, 50825 Koeln fax: +49 6224 9259 333 Geschaeftsfuehrer Harald A. Summa http://www.de-cix.net Registergericht AG Koeln HRB 51135 ------ End forwarded message ------

1 0

Re: [tt-tf] TTM futures - new draft
by Mark Dranse 23 Apr '07

23 Apr '07

Hi Brian, Thanks for your kind comments. I'll attempt to address each of your points in turn. On 19/04/2007 12:56, Brian Nisbet wrote: >> Vision >> ~~~~~~ >> >> Our goal is to expand and maintain the TTM network, increasing the value >> of the service to the community at large and to the owners of the >> probes. This will be achieved by making improvements in the following >> areas: >> - Enhancing the measurement architecture >> - Enhancing the TTM network architecture >> - Improving alarms and reporting >> - Improving the business model > > Are there any notions of time-scales along with these proposals? At present, this is just a draft. We need consensus from the community, which I hope will come from these on-list discussions, and from the WG meeting at Tallinn. After that, we can take the plan to the Board for executive approval. Once approved, we will begin the real work on this, which will lead to a proper project plan with milestones and timescales. That's the political answer. Back in the real world, I'd like it if most of this could be done over the coming year. But please don't take that as a firm commitment. >> TTM network infrastructure >> ~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 1. For the services that the TTM provides, it is essential that there >> are enough active probes at interesting locations. At present, we are >> relatively limited by the availability, and geography,of those willing >> to sponsor probes, and as a result, some rather dense and unhelpful >> clustering has occurred. A possible solution to mitigate this problem is >> to install a number of probes at important locations for free. The NCC >> will fund the hardware and service contract, while the host will support >> the probe with power, connectivity and remote-hands. Rough criteria for >> hosting a box: >> >> - Major AS or IX >> - Only one free box per AS – if a site wants more, they have to pay >> - Commitment from the site to operate the box for a minimum 3 year period >> - Selection will be a “beauty contest”, and at the discretion of the NCC > > This is vital and will, hopefully, attract a decent amount of > respondents. I hope so too. Does anyone else have any comments regarding this? >> 2. However this alone will not ensure sustained growth of the network. >> This needs to be addressed by increasing the number of sponsored probes >> and ensuring that those probes are well maintained and upgraded when >> necessary. Therefore It is important to make the TTM services attractive >> to sponsors of the TTM probes to increase stability and steady growth of >> the network. Several incentives can be provided: >> >> - Allow the sponsor to define their own measurement mesh and specific >> routine measurements (level of detail and frequency). Management of >> gathered data will be the responsibility of the sponsor. >> - Support the sponsor in creating dynamic meshes to monitor their own >> applications and services, providing a global picture of availability. > > While I think that it will be a pity (as I have voiced previously) > to lose the fully-meshed nature of the TTM network, I would not > for one moment suggest that this step is not necessary, and it is > one that will hopefully present a clearer business case for TTM. By way of clarity, we're not proposing losing the full mesh. This is a fundamental and integral element of the architecture, and fully meshed measurements will continue for the foreseeable future (the only argument I can see for them stopping is if the sheer volume of measurements becomes too high as a result of enormous network growth - a nice problem to have at some point in the future!) What is being proposed is the addition of support for locally customised meshes so that probe sponsors can carry out measurements of specific local interest to them. It's very much an augmentation, not a replacement of current functionality. >> TTM Measurements >> ~~~~~~~~~~~~~~~~ >> >> 1. Near real-time measurement of application services >> The TTM network will continue to act as a measurement platform for >> critical Internet public service and infrastracture applications (e.g. >> root and ccTLD DNS monitoring and of multicast performance). These >> independent tests are of benefit to the service administrators, the end >> users, and to the hosts of TTM probes. We will improve this service by > > The near real-time measurements are of great importance to us in > HEAnet and I am very pleased to see they are not in danger. > >> Reporting >> ~~~~~~~~~ >> >> We consider the current reports to be complex and overwhelming. We will >> simplify the presentation of results to include fewer pre-generated >> plots, and shift our focus to the identification of trends and changes >> in gathered data. We will continue to support tools to generate plots on >> demand, and raw data will continue to be available for analysis. DQM >> will be used to verify data sanity. In addition to this, we are >> investigating ways to merge TTM data with that from other services - >> such as RIS - combining data from these powerful platforms to display >> broader and more representative pictures of Internet behaviour in near >> real-time. > > This really does seem to be the best of all possible worlds. > >> Admin and pricing model >> ~~~~~~~~~~~~~~~~~~~~~~~ >> >> As a result of feedback from existing TTM hosts, we intend to move to a >> single up front payment. This payment will cover hardware, setup, and >> three years of service fees. After three years, the host may >> re-subscribe, or opt to stop participating. > > This makes a lot of sense. It's possible that this is a question for > the infrastructure section, but I would very much like to hear more > detail (although perhaps not appropriate to this discussion) on the > hardware plans for the full TTM boxes. Some of the hardware out there > is getting old at this point and might it be useful to have an upgrade > path available for those who have been part of the project for some > time? I'm not really asking on behalf of HEAnet here, more wondering > if continued participation by commercial entities could be ensured > by sweetening such a deal? You raise an interesting and valid point. Hopefully I'll have an answer to this by the time we all meet in Tallinn. > Once again, thanks for all the work that obviously went into this > proposal. And thank you for your comments and queries. I'm interested in seeing some more traffic on this topic prior to RIPE54, so I encourage anyone else who reads these emails to share their thoughts. If you're part of the silent majority, please try to share just a few comments with us - be they in support, or (perhaps more importantly) otherwise. Mark -- Mark Dranse RIPE Network Coordination Center Information Services Manager Singel 258 Amsterdam NL http://www.ripe.net +31 20 535 4444

1 0

TTM futures - new draft
by Mark Dranse 12 Apr '07

12 Apr '07

Dear Task Force, Based on feedback previously provided, below you will find the new outline of our plans for future direction of the TTM network. We appreciate you taking the time to read this draft proposal, and are very eager to receive any and all feedback you may have on the general plan, or any specific element of it. We expect this discussion phase to be completed by RIPE 54 in May, and therefore would appreciate you feedback by 27th April. Vision ~~~~~~ Our goal is to expand and maintain the TTM network, increasing the value of the service to the community at large and to the owners of the probes. This will be achieved by making improvements in the following areas: - Enhancing the measurement architecture - Enhancing the TTM network architecture - Improving alarms and reporting - Improving the business model These changes will require a radical rethink in probe and measurement architecture, resulting in new structures for the probes themselves, and the tests they carry out. TTM network infrastructure ~~~~~~~~~~~~~~~~~~~~~~~~~~ The TTM network is the foundation of the TTM and associated services. Therefore, these services strongly depend on reliability and coverage of the network. In particular it is essential that there are many active probes at interesting locations, that probes are well maintained, and that coverage can be further increased by deploying simpler devices. Let's consider these goals separately. 1. For the services that the TTM provides, it is essential that there are enough active probes at interesting locations. At present, we are relatively limited by the availability, and geography,of those willing to sponsor probes, and as a result, some rather denseand unhelpful clustering has occurred. A possible solution to mitigate this problem is to install a number of probes at important locations for free. The NCC will fund the hardware and service contract, while the host will support the probe with power, connectivity and remote-hands. Rough criteria for hosting a box: - Major AS or IX - Only one free box per AS – if a site wants more, they have to pay - Commitment from the site to operate the box for a minimum 3 year period - Selection will be a “beauty contest”, and at the discretion of the NCC 2. However this alone will not ensure sustained growth of the network. This needs to be addressed by increasing the number of sponsored probes and ensuring that those probes are well maintained and upgraded when necessary. Therefore It is important to make the TTM services attractive to sponsors of the TTM probes to increase stability and steady growth of the network. Several incentives can be provided: - Allow the sponsor to define their own measurement mesh and specific routine measurements (level of detail and frequency). Management of gathered data will be the responsibility of the sponsor. - Support the sponsor in creating dynamic meshes to monitor their own applications and services, providing a global picture of availability. 3. To further expand the network in the areas where support and technical expertise are limited (e.g. small/residential customers), a probe itself should be as lightweight as possible (no GPS, embedded systems). The CBM proposal fits well in this category. This setup doesn't allow one-way measurements, although an aggregated view from a cluster of such lightweight probes can enhance the TTM and add-on services. TTM Measurements ~~~~~~~~~~~~~~~~ 1. Near real-time measurement of application services The TTM network will continue to act as a measurement platform for critical Internet public service and infrastracture applications (e.g. root and ccTLD DNS monitoring and of multicast performance). These independent tests are of benefit to the service administrators, the end users, and to the hosts of TTM probes. We will improve this service by - Considering measuring new applications as the need arises - Making reporting clearer (see below) - Enhancing alarm functionality (see below) - Implementing the CBM proposal (see infrastructure section) 2. Global one-way measurement platform The TTM network will continue its one-way measurements of the delay/jitter/loss between the distributed probes. These independent tests are of benefit to the hosts of the TTM probes, to the broader community, and to specific interested organisations who rely on neutral views (e.g. regulators and governments). We will improve this service by - Introducing custom measurement meshes (see infrastructure section) - Introducing support for OWAMP. This will allow the TTM network to interact with other compatible networks, and will facilitate measurements on demand (subject to access restrictions) - Setting up data quality checks to ensure the sanity of presented data - Making reporting clearer (see below) - Enhancing alarm functionality (see below) 3. General purpose distributed measurement platform for ad-hoc experiments The TTM network will be developed to enable interested parties (e.g. CAIDA) to conduct a variety of time-limited, global, local, or mid-range experiments (for example the k-root anycast studies). An outcome will typically be an analytical report that will be open to the community. Reporting ~~~~~~~~~ We consider the current reports to be complex and overwhelming. We will simplify the presentation of results to include fewer pre-generated plots, and shift our focus to the identification of trends and changes in gathered data. We will continue to support tools to generate plots on demand, and raw data will continue to be available for analysis. DQM will be used to verify data sanity. In addition to this, we are investigating ways to merge TTM data with that from other services - such as RIS - combining data from these powerful platforms to display broader and more representative pictures of Internet behaviour in near real-time. Alarms ~~~~~~ We consider the current alarm functionality to be complex and overwhelming. This will be re-engineered to provide more powerful network and application alarms. We will enable users to run a variety of NCC defined tests, limited by number, frequency and longevity, so as to ensure that these tests do not impact public TTM network operation. As with reporting, we will simplify presentation of generated alarms to make them clearer. Admin and pricing model ~~~~~~~~~~~~~~~~~~~~~~~ As a result of feedback from existing TTM hosts, we intend to move to a single up front payment. This payment will cover hardware, setup, and three years of service fees. After three years, the host may re-subscribe, or opt to stop participating. -- Mark Dranse Information Services Manager RIPE NCC

1 0

Re: TTM Service 2007 - 2009
by Henk Uijterwaal 26 Sep '06

26 Sep '06

Brian, >I tried to send this to tt-tf(a)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.

1 0

Fwd: Re: TTM Service 2007 - 2009
by Henk Uijterwaal 26 Sep '06

26 Sep '06

>X-Original-To: henk(a)ripe.net >Delivered-To: henk(a)ripe.net >Date: Tue, 26 Sep 2006 10:07:18 +0100 >From: Brian Nisbet <brian.nisbet(a)heanet.ie> >User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) >X-Accept-Language: en-us, en >To: Henk Uijterwaal <henk(a)ripe.net> >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(a)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 TBs 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(a)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.

1 0

TTM service 2007-2009
by Henk Uijterwaal 22 Sep '06

22 Sep '06

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 TBs 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 dont 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.

1 0

TTM Task Force/TSC clock.
by Henk Uijterwaal (RIPE NCC) 08 Sep '06

08 Sep '06

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 ------------------------------------------------------------------------------

1 0

TTM Task Force
by Henk Uijterwaal 06 Sep '06

06 Sep '06

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.

1 2

Re: TT-TF charter
by Henk Uijterwaal 30 May '06

30 May '06

Dear All, >At RIPE52, you voluntered as a member of a Test Traffic Task Force >(TT-TF). To get the ball rolling, I've written a charter. Can you please >confirm your interest and let me know if you agree with the charter? >After that, I'll set up the mailing list and we can start the real work. I just did this, the mailing list for the group is tt-tf(a)ripe.net and I did a mass subscription for the people who confirmed their interest. 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. Watch this space...

1 0