- mat-wg - mailman.ripe.net

RIPE Atlas has Reasons to Celebrate
by Mirjam Kuehne 22 Dec '11

22 Dec '11

[apologies for duplicate mails] Dear colleagues, We are proud to announce that over 1024 RIPE Atlas probes are now active, distributed over the whole world! This is an important milestone. Thank you all for making this possible. Read more on RIPE Labs: https://labs.ripe.net/Members/becha/ripe-atlas-has-reasons-to-celebrate Kind regards, Mirjam Kuehne RIPE NCC

1 0

New RIPE Labs: RIPE Atlas & Anycast Instance Switches
by Mirjam Kuehne 22 Dec '11

22 Dec '11

[apologies for duplicate mails] Dear colleagues, RIPE Atlas can now test packet flows from more than 1000 vantage points on the Internet. We took a quick look at anycast traffic to DNS root name servers. There is a lot of interesting signal in this data. See the results on RIPE Labs: https://labs.ripe.net/Members/dfk/ripe-atlas-and-anycast-instance-switches Kind Regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: The Curious Case of the Crooked TCP Handshake
by Mirjam Kuehne 14 Dec '11

14 Dec '11

Dear colleagues, Emile Aben and Geoff Huston wrote an article an article about the behaviour of the Linux implementation of TCP, and looked at the way in which TCP establishes a connection. You can read it on RIPE Labs: https://labs.ripe.net/Members/gih/the-curious-case-of-the-crooked-tcp-hands… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: 128.0/16 As Seen from RIPE Atlas
by Mirjam Kuehne 13 Dec '11

13 Dec '11

[apologies for duplicate mails] Dear colleagues, As a follow-up to the recent article "The Curious Case of 128.0/16", we now looked at 128.0.0.0/16 as seen from RIPE Atlas: https://labs.ripe.net/Members/dfk/128.0-16-seen-by-atlas Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [mat-wg] [routing-wg] [ncc-announce] 128.0.0.0/16 configured as martians in some routers
by Daniel Karrenberg 05 Dec '11

05 Dec '11

On 05.12.2011, at 16:51, Bengt Gördén wrote > > Maybe atlas could come in handy here? > > > regards, > > Bengt Gördén > Resilans AB Bengt, in fact some of our beta testers for "User Defined Measurements" thought so too and started measurements. At the moment the maximum number of probes they can use per measurement is 10. So this is not entirely representative. Plots are "dnsmon" style, so green=good & red=bad. There is more green than red, that is encouraging. Even more encouraging is that probe #899 actually got connectivity today. Congratulations to AS39759 from the beatiful Republic of San Marino! We will work to make a more representative measurement as soon as possible. Daniel

2 2

Notes from the TTM workshop @RIPE63
by Vesna Manojlovic 02 Dec '11

02 Dec '11

Dear colleagues, please find attached the notes from the brainstorm-meeting during RIPE63 in Vienna, where we had a room full of people bring up their experiences and wishes for the future of the Test Traffic Measurement (TTM) service. My apologies for the delay. I am attaching the full, raw notes, for the historical record, and a basis for further discussion. However, you may prefer the summarized list (below). Please add any comments and ideas. We are working on the evolution plan and road-map, and all your feedback is appreciated to guide us. And finally, a poetic illustration of one of the concepts suggested at the meeting. Regards, Vesna Manojlovic Feature requests and updates to TTM (hardware and software) * Improve interface so that non-technical people can get reports (two modes). Make it easier to see the data in general * Changes to the API to do your own presentations, reports, and integration into monitoring systems; more raw data * Useful alarms which are configurable * Multiple ethernet, insight into layer 3, TTM boxes talking to each other * Antenai sharing * Use taildaemon - share tailport amongst TTM users * TCP port randomisation * User-defined measurements * Expanded information: where is the bottle neck, performance problems between two points * Adjustment of sampling, higher sampling rate * Open-source the software New uses for TTM boxes, data * Combine Atlas and TTM into an active measurement services system. TTM becomes an anchor and target - a sort of powerful Atlas probe * Put data as quickly as possible in a central database and make it accessible, correlate with RIS -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net Notes from TTM workshop, 1.1.2011. Vienna, RIPE63 Chair: Daniel Karrenberg, Chief Scientist, RIPE NCC Daniel: TTM is getting a bit old, and there are other active measurement structures: DNSMON, Atlas. TTM has been a bit neglected; we want to re-establish contact with hosts, and see how TTM fits into other activities. We already did a mini-survey and published results: https://labs.ripe.net/Members/dfk/ripe-ttm-user-survey-results Let's do the around-the-table introduction, to see how people are using it, take your view on how TTM should evolve. Sean, RIPE NCC: I maintain the system; I can answer questions about current operation. Jari Miettinen, FUNET: hosting box #34. Main purpose is time-source (seconded by George form APNIC). Data should be made easier to use; better reports for non-techies. Two paths--one for technical people and one for others. Antionio Moreiras, NIC.br: hosts 5 boxes. Using TTM to see how Brazilian internet connect is with the rest of the world. Wants TTM continued; we likes it. Evolution: easy way to see the data (have done some things themselves, such as world map); realtime data very useful. Uses one-way delay measurements which are not available with other tools like Atlas. Feature request: use of taildaemon - share tailport amongst ttm users. Own software does not scale, cannot be used for more probes. (During RIPE63, Antonio gave presentations on their TTM use: http://ripe63.ripe.net/presentations/170-ttm-real-time-nic-br.pdf http://ripe63.ripe.net/presentations/45-ipv6-ipv4-latencies-ripe.pdf Yoshinobu Matsuzaki, IIJ: We have 2 boxes, in Japan and USA. Also used as tiemsource. Doing DNS anycast measurements, and using one-way delay measurements. Martin Pels, Ams-IX: They had 4 boxes; Used to use them to measure one-way delays on switching platform. Platform evolved, infastructure too complex for existing TTM. Now using it as a time source for other measurements boxes. Useful addition would be: tcp source port randomisation (way to better define the measurements from fixed source ports?) & would like more insight into layer 3 specifics (seconded by someone). Sebastian Castro, .NZ (#182): Interested in Raw Data to build own system on that. Boxes around the world useful to test visibility, monitor DNS anycast. Addition feature request: ability to run small DNS tests on other boxes, and collect the data. (User Defined Measurements) Nigel Titley, Easynet: used requirement for pretty graphs as the original argument. It took 2 years to install GPS :( By the time it was running, management directive had gone away. Using as a timesource. Hoping we can get something out of TTM + Atlas to get pretty graphs to send to customers. Thomas Schmidt, DFN: Room for improvement in presentation of data. What is the vision of the project? I would like to get information about where is the bottleneck, performance problems between A&B, pinpointing info, possibly reroute traffic accordingly. Would like to see more correlation of the data: traceroutes & one-way delay measurements. (DFK translated this into "automatic troubleshooting system) Alarming system would be nice... George Michaelson, APNIC: We have one box in APNIC infrastructure, and sponsored 10 boxes in AP region: We are using it as a timesource, but it was a huge value added in AP region - people were hugely supportive of this, because there is no other infrastructure to provide accurate time. Also used for "up or down" tests, that's useful (also for PR). Christian Panig, ACOnet: no regular use, not integrated into operational cockpit. happy to provide it as a service for others to use the data. Wilfried Woeber, ACOnet: have had it many years, doesn't require much care & feeding, it's just there (close to the core). Looking at path between endpoints/various TTM boxes (in Asia in particular) and examine from both ends was most recent useful use. Interesting thing is to have a one-way look onto infrastructure (not necessarily one-way delay measurement). To be able to pick out strategic boxes and see what they pass on about our network. Presentation: I think the approach Atlas takes is much more modern and user-friendly, but if you want to dig into a particular case, TTM gives good info, but you have to pull it together yourself. TTM is a good thing to have. Geoff Huston, APNIC: I find time-source valuable usage. We are also involved with Atlas, think there's some benefit in folding them together. Like to see development that makes them targets for atlas nodes (many people agreed) Dave Wilson, HEANET: does get used from time to time, but it is very occassional. It has been invaluable for some specific troubleshooting, rest of the time it isn't used. We (at GEANT) are inventing some of the same wheels RIPE NCC is. Nothing actually gets deployed and used unless it is part of a regular system--therefore it must have an API for someone to want to do development. TTM - I know how to interpret it, but visualisation shows what data is there, not info we need. Third, aware that RIPE projects are competing with the projects we are doing - and everyone is losing. We should work together. Brian Nisbet, HEANET: It is very old, visualization is old, it was used operationally originally, but not now, because people don't know the interface and aren't interested. Can't persuade people to use very useful data. And we use it as time source :) Fredrik Pettai, NORDUNET: used as a timesource. future use: things mentioned by Thomas and Dave & Brian: we don't use it because the interface is old, alarms are not that useful so turned off. Don't know how to make alarms more useful. Most TTM boxes are centrally placed with good connectivity, so there are no useful alarms produced. Wolfgang Tremmel, DECIX: We have 12 boxes, and we are *not* using any as a timesource! Use as measurement and proof for SLA with customers. Measure delay, packetloss, between customer and switches. Room for improvement: a lot. Not guy running it, guy is not here until Thursday. Would like hardware improvement--as many NICs (Ethenet interfaces) per box as possible. Antenai sharing - running a cable to the roof requries tons of permissions so sharing between 2-3 boxes in the same building would be a great improvement. Interfaces API: would li ke to see API based on modern technique like SOAP. Adjustment of sampling, like higher sampling rate. Boxes in same city, want many more packets; adjustment of IP source and destination wanted (user control measurements (packet parameters)). Any plan to open source the software? Stephan Wahl, ECIX: API is very important, second Geoff - onion model with TTM and Atlas. Small atlas probes could help fill in white spots in the TTM map, adding granularity. TTM shows well-connected nodes, interested in access layer. Timesource - there are other options which are cheaper than TTM Sascha Pollok, IPHH: we mainly use it as a reference for good quality traffic. Put where customer service is connected so we can graph things and show it to customers to show it isn't their fault. Independent source. Fancy graphs, API to generate graphs wanted - not require customers to go to RIPE for this. Web interface looks rather old-fashioned. Co-workers don't like to use the web interface. Not quite sure if TTM is already providing this: alarms... (whatever it was is very rudimentary, says Daniel). Atlas integration = cool. Additional traffic to Atlas hosts would be quite small, depending on # of TTM boxes. Today we can send customers to DNSMON graphs. Christian Kaufmann: Here as MAT-wg co-chair. Randy Bush, IIJ: Atlas seem to be running behind NATs, when people talk about having them play together, with my operator's hat on I think it could be useful to tell customers to get atlas probes which will allow them to see how their link to us is doing--how your reachability, performance is. That would make Atlas probes useful in a customer relationship. Vaclav Novak, CESNA : use it as time source; Luisa Villa, LACNIC: here just to bring feedback back to LACNIC. Serge Krashakov, Chernogolovka (tt143): not using it intensively. Not quite sure we should continue using it. Main problem ... internal connectivity cannot be tested. ... and lack of Russian TTM nodes . Matthias Kluth (TTM #101 - HeliNET): found it useful to have an independent view on the network. Integration with Atlas. Daniel Karrenberg summarized: TTM is mostly used as timesource. Data presentation is deficient: dated, time lag too big, presentation needs to be adaptable to specific users, correlate the data. Call for an API in order to do your own presentation and integrate it into cockpits & monitoring - and produce "pretty graphs". Demand for useful alarms that are configurable. One-way-delay measurements also appreciated. General positive attitude toward integration with other active measurements products in particular Atlas. Target idea is good. Couple of requirements from IXP crowd - divided: someone else is using a different commercial product, some would like to see TTM have multiple ethernet, insight into layer 3, TTM boxes talking to each other, etc Christian Panigl: Might be interesting to offer TTM beacon and let people who are interested in measuring their so called broadband measure against regional or national exchange service. (Daniel: put something in a place so well connected that it can't be the bottleneck) Daniel: the last mile won't be the problem of the future. Wilfried: Atlas is much more modern and compatible with today's expectation, in that it includes upper-layer servcies, like trend graphs. TTM was built on purpose to just do lower layer, but these days we would rather have something which gives us a broader picture. (e.g., what is the quality over time from this vantage point when the infrastructure might change.) Daniel: telling personal current vision on how to evolve this. Interested in onion model. Not Atlas and TTM, just active measurent service. Morphed TTM into anchor/target sites that can do two things (powerful Atlas probes for active easurements, user controlability, also use Geoff's suggestion to make them targets). Atlas probe can now do everything except the one-way delay that TTM can do. Might be room for third size in between. I would like to do that but I fear we will lose focus if we do it immediately. Personally I'm not so convinced that RIPE NCC should expand a lot of energy in making it very very suitable to measure metropolitan area stuff. I need to know that's in the interest of the community. I'd like to be convinced. But quite frankly, there are commercial solutions for that. There is a conflict here. Put data with as little lag as possible into central database to make it accessible. Needs to be distributed to remove bottleneck/point of failure. Put data together, correlate with RIS, ... Also expand energy to get data opened up as uch as possible, not just through API, making it possible to combine with other initiatives to bring things together, benefit of more raw data, enable many people working on presentations. Wolfgang: with all those requirements there is one thing that makes up most of the complexity which is also the differentiator between this and Atlas: one-way measurements. Some people using it, some find it not so useful. What priority does this have to you? Would a round-trip be as useful? There was disagreement with this proposal--one way measurements are the core. Dave: want to correlate with RIS, just don't want to fall into trap of "here's what we have, how can we use it?" Daniel: data gathering and presentation has been split deliberately within RIPE NCC. Idea is to have two groups, one who creates database, and one who try to get something out of it. (Wolfgang's and Robert's teams) Antionio Moreiras: concerned that people are using TTM as primary timekeeping. Daniel: thank you for being here, any details get in touch with Ann and Vesna. Their role is to stand up for users. You can talk to developers as well, but Ann and Vesna are user advocates, make use of that. ÒThe Future of TTMÓ workshop, RIPE63, Vienna Tuesday, 1.11.11., 1PM, Schonberg room (lunch meeting in a separate room) List of participants: Number, name Organisation TTM box Wilfried Woeber ACOnet #73 Christian Panigl ACOnet #73 Stefan Wahl Peering.eu n/a Nigel Titley Easynet / NCC EB#154 George Michaelson APNIC #157 Jari Miettinen FUNET #34 Thomas Schmid DFN #77 Christian Kaufmann MAT-wg chair n/a Wolfgang Tremmel De-CIX Many Brian Nisbet HEAnet #35 Matthias Kluth HeLi NET #101 Sebastian Castro .nz registry #182 Martin Pels AMS-IX #121 Serge Krashakov Chernogolovka #153 Sascha Pollok IPHH #162 Fredrik Pettai NORDUnet #8 Vaclav Novak CESNET #133 Antonio Moreiras NIC.br #159 Yoshinobu Matsuzaki IIJ #103,#129 Geoff Huston APNIC n/a Luisa Villa LACNIC n/a Dave Wilson HEANET #35 Randy Bush IIJ #129 Vaclav Novak CESNET #133 RIPE NCC staff: Ann Barcomb Daniel Karrenberg Erik Romijn Sean McAvoy Vesna Manojlovic Wolfgang Nagele

1 0

Today's RIPEstat demo session
by Mirjam Kuehne 29 Nov '11

29 Nov '11

Dear colleagues, Don't forget: Today's RIPEstat demo session starts in one hour at 10:30 UTC (11:30 Amsterdam time). Please find more details on RIPE Labs: https://labs.ripe.net/Members/kistel/ripestat-live-demo-11 Kind Regards, Mirjam Kuehne RIPE NCC

2 2

Next RIPEstat Live Demo Scheduled for Next Week
by Mirjam Kuehne 22 Nov '11

22 Nov '11

Dear colleagues, Please mark your calendars: The next RIPEstat live demo session is scheduled for next week Tuesday at 10:30 UTC (11:30 Amsterdam time). More details can be found on RIPE Labs: https://labs.ripe.net/Members/kistel/ripestat-live-demo-11 Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Re: [mat-wg] [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member
by Daniel Karrenberg 08 Nov '11

08 Nov '11

[cronss-posting to MAT WG as it is pertinent there as well] On 04.11 08:21, Henk Uijterwaal wrote: > ... > > 150 euro/year is of the order of 2-3 engineer hours, somewhat depending > on the economy where you are living. > > > Products from these measurements are useful for detecting anomalies, > > monitoring trends and for analysing faults. > > What product is currently included in the probes that solves an issue > that most AS's have _and_ where the data from the probe can be used to > solve the problem much faster, where much faster means 2-3 hours less > work on an annual basis? Right now, I don't see such application. Is > there something in the pipeline that we haven't heard about? Thank you Henk for putting the cost in terms of something as tangible as this. This message is long because of the number of scenarios. If youa are pressed for time, jump to "Summary". Here are a few scenarios that come to mind: - Monitor Traffic Engineering Results How does my traffic engineering affect actual latencies and losses? Does TE even do what I expect? Today traffic engineering is mostly monitored by comparing inbound flows from different peers before and after some actions. It can be difficult to even tell what path traffic takes or will take from a specific source. With RIPE Atlas widely deployed and user defined measurements (UDM) in place you can check inbound trajectories by running traceroutes and inbound latencies by running pings and application measurements from distant areas of interest towards your network. This gives you insights that are very hard to obtain otherwise in a comprehensive manner. Also the measurements will be useful when debugging with your peers and upstreams because they come from the RIPE NCC, a well respected source and everyone will be familiar with them. I can easily see how you can save 2-3 engineer hours per year right here by eliminating guessing time and speeding up analysis. - Is it slow for just me ? We all know this scenario: An important customer complains that he cannot get to his favourite content in Distanistan. Or a content customer complains that for "weeks" their hits from Distanistan have decreased. Of course you can check it out right now from the perspective of your network. But how about the pespective from Distanistan or a comparison with others in your region? With RIPE Atlas widely deployed you could set up a measurement from many different places around your region to Distanistan for a week or so and compare. It is even likely that there is a probe in close vicinity of Distanistan which can measure towards your network. If others have had problems with Distanistan too, it is likely that they have set up measurements already. All measurements are available in the RIPE Atlas pool of measurements. You can access those measurements right when the customer complains. At a minimum this may give you the opportunity to explain to the customer that everyone, not just you, has a problem and to prove it with measurements from an independent source, the RIPE NCC. The measurements will also allow you to concisely point out the problem to your peers and up-streams. I can easily see how this will both save hours of engineering time, make the results of trouble shooting better and help you be more credible with customers. - Situational Awareness Today, the routing plane is very well instrumented and we regularly see "events" discussed on operational lists. Very often the effects of these events on the transport plane are subject of speculation, guessing and the occasional isolated measurement. A widely deployed RIPE Atlas will improve our situational awareness by giving us near real time insight into the changes in latencies, packet trajectories and packet losses which are caused by events on the routing plane. The pool of RIPE Atlas measurements will be a treasure trove from which we can isolate signals both on the geographical and topological level. We can correlate them with events in the routing plane and gain a much better insight into the state of the Internet as a whole. A widely deployed RIPE Atlas will become a common frame of reference for dealing with regional and global events that involve many ASes. Having such a global frame of reference will in itself save many engineering hours by enabling quick, concise and unambiguous communication about events on the transport plane between routing engineers. - Long Term Comparative Analysis How are we doing compared to others in our market, region, the world? This is a common question. A widely deployed RIPE Atlas will help you answer those questions from an outside view in terms of stability, packet loss and latency. The measurements will be comparable and they come from a trusted external source. Building an infrastructure to do this ourselves is beyond the resources of most or even all of us. Doing it together makes this possible. For the equivalent of just 2-3 engineering hours per year we can make it happen. - Summary Referring to a common, well known measurement platform for the transport plane will save many engineer hours just by speeding up communication and preventing misunderstandings. RIPE Atlas will improve communications with your peers, up-streams and sophisticated customers by introducing hard transport plane data and a common frame of reference. RIPE Atlas will bring to the transport plane what we already have for the routing plane with route views and RIS. This alone will save more than 3 engineering hours per year for everyone. Add the unprecedented situational awareness of actual latencies, packet losses and packet trajectories and the credibility of the RPE NCC as a source of data, then one RIPE Atlas probe for every RIPE NCC member becomes a baragin. I realise thatwe have not realised most of the products I talk about. However we do have the architecture in place and almost 900 probes out there now. We also have some first examples of useful products: http://atlas.ripe.net/atlas/rtt_maps.html?msm_id=1001 http://atlas.ripe.net/atlas/comparative_root_rtt.html https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-in-the-making AS a probe host you can also look at measurement results from a large number of public probes at http://atlas.ripe.net/atlas/myprobes.html after registering. In the coming 6 months we will deploy user defined measurements and the measurement pool. We will also show more "map" products for situational awareness. We will convince you that speeding up RIPE Atlas deployment by providing at least one probe for every member is worth it. I am sure we can even convince the executive board that we should start this already in 2012 and not wait for the 2013 budget cycle. Watch this space. Daniel

2 1

New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member
by Mirjam Kuehne 04 Nov '11

04 Nov '11

[Apologies for duplicate mails] Dear colleagues, RIPE Atlas has made steady progress in its first year. But we have more ambitious plans. Read in this new article on RIPE Labs how we want to achieve these plans and why we need your support: http://labs.ripe.net/Members/dfk/a-ripe-atlas-probe-for-each-ripe-ncc-member Kind Regards, Mirjam Kuehne RIPE NCC

3 2