You're viewing an archived page. It is no longer being updated.
Date: 18 November 2015, 14:00-15:30
Chair: Christian Kaufmann
Scribe: Suzanne Taylor
Christian welcomed everyone to the session and apologised for Nina, who couldn't be at the meeting.
Christian asked whether there were any objections to the draft minutes from the RIPE 70 MAT Working Group session. There were no objections and he declared the minutes approved.
He asked the session attendees to please rate the session presentations and give feedback about what they find interesting and what is useful in terms of content.
Christian reviewed the session agenda; there were no changes.
Dario Rossi, Telecom ParisTech
This presentation is available online:
https://ripe71.ripe.net/presentations/52-drossi-RIPE71_MAT_CGN.pdf
Alexander Iyamin, Qrator Labs, commented that some recent research hypothesised that IPv6 is faster than IPv4 because IPv4 gets bogged down by NAT performance. He suggested that Dario's presentation proved that paper wrong. Dario responded that his research does not prove the paper wrong, but that in their research setting, with the particular carrier-grade NAT (CGN) and operator, etc., they didn't see any impact on performance. He added that his contribution is really in determining whether any performance impact seen is the fault of substandard equipment.
Alexander commented that, when using poor equipment, both IPv4 and IPv6 will be affected similarly. Dario explained how the research methodology can identify whether poorly performing equipment is to blame for the impact on performance.
Gert Doering, SpaceNet, said the methodology was interesting and that he was surprised to see CGNs had no impact on performance; however, he said this was not necessarily bad news. He added that CGNs scale up to a certain amount of parallel flows and throughput and that if capacity is only at 90%, he wouldn't expect them to have any impact. He also said that HTTP is an easily handled protocol and that he's heard about users in Germany sitting behind CGNs who have issues with SIP because the SIP register goes out to the SIP provider, and a few seconds later the CGN expires the session so that, when the call comes in, the CGN has no idea who the user is. As a result, he said, SIP behaves very erratically behind a CGN. He explained that this is a difficult protocol for a NAT to handle because it's UDP, you don't have a TCP FIN, and there might be no activity for minutes. He said that this was just something to consider for further study.
Dario responded that, with this data set, they looked at VoIP and not SIP, but that it's something worth studying. He added that they didn't just look at HTTP but also peer-to-peer traffic, including UDP. He said the study was more about the methodology, but that he appreciated the feedback.
Bengt Gördén, Resilans, asked whether Dario based his figures on the percentage that actually needs a server a home. Dario asked for clarification, and Bengt said that Dario scanned for HTTP, IMAP, SMTP, and that mostly you can't use it at home. Dario said that the 0.6% figure from his presentation that Bengt was referring to was a complementary study and was relevant only to that user population, and that it wasn't the main point of the research.
Jelte Jansen, SIDN, said he wanted to add a “+1” to the request for more protocols beyond HTTP. In addition to SIP or VoIP, he said that, for example, the gaming community uses local services just to set up sessions. He also asked about peer-to-peer traffic, which he said was another big concern because a number of streaming services use peer-to-peer
Dario responded that they were trying to establish some correlation among flows because they didn't see any impact with single flow. He said they want something closer to the user, such as looking at what the correlation is between SIP and VoIP. He said they are not equipped to look at gaming, but that if there is something else of interest that is easy, he would look at that.
Jelte suggested that they could possibly try to detect failed connection attempts at the CGN point. Dario agreed that a view of internal counters to correlate with performance would be easier, but that the probes are passive and they don't control the CGN, so they are somewhat limited by their methodology.
Robert Kisteleki, speaking for himself, said that he wanted to make the choice about whether to run a firewall (rather than his ISP deciding this for him) and was happy that Dario called this a “side effect” and not a “feature”. He also asked whether Dario had considered the fact that, with CGNs, it will become more and more difficult to determine people's geolocation, so CDNs and content providers will have a harder and harder time routing content to an individual because they will no longer know their location.
Dario responded that there is EDNS, a client extension, but Robert responded that people don't really use such things. Dario said that this is being increasingly used in the measurements community. Robert suggested that this issue might deserve further study. Dario responded that the round-trip times they measured could potentially shed some light on this issue. Robert commented that it is less of an issue for small ISPs, but larger ones, such as Comcast, have many exit points and this could cause problems. Dario agreed.
There were no further questions.
Brian Trammell, ETH Zurich
This presentation is available online:
https://ripe71.ripe.net/presentations/63-ripe-mat-mplane-ptrans.pdf
There were no questions.
Dario Rossi, Telecom ParisTech
This presentation is available online:
https://ripe71.ripe.net/presentations/88-drossi-RIPE71_MAT_anycast.pdf
The first part of the presentation was given during the plenary session and is available online:
https://ripe71.ripe.net/wp-content/uploads/presentations/51-drossi-RIPE71_vFINAL_dario.pdf
Robert Kisteleki, RIPE NCC, said that the RIPE NCC has data available, including traceroutes run on MCIP, to help answer some of the questions Dario raised during his presentation. He added that they use an automated geolocation finder when RIPE Atlas probe hosts don't explicitly give their location and use MaxMind for this. He said they don't know how accurate this data is, but that they use system tagging to let users know that these locations were not given by the hosts themselves. He said they understand that some people give incorrect locations due to moving, etc. and that more and more people are coming up against this issue, so he expects they will spend some effort on this.
An attendee thanked Dario for his research and said it was particularly interesting for CDNs and for researches in determining the best location for anycast nodes. He added that latency is not limited to the latency of fibre, and that in most cases, we should use different locations and analyse which hops are actually travelled. He said that the main problem with geolocation is that latency varies so much from ISP to ISP and that there are a lot of middle nodes that add significant latency. He suggested that Dario should limit his research to 10 nodes within 100 km radii.
Dario said he agreed that the latency figures are not good and that they should be considered only as an initial guess. He said that anywhere within a certain radius of their point of origin there are places of interest, but that they no longer look at latency beyond that; they simply choose the biggest cities. He said that, using this methodology, in 75% of cases they are right. When they are not right, he said, you have to look at how large your radius is, which can be as big as 1000 km and then latency can be quite bad. He added that they do 100 measurements and then pick just the most relevant ones.
There were no further questions.
Vesna Manojlovic, RIPE NCC
This presentation is available online:
https://ripe71.ripe.net/presentations/107-ripe71-ripe-atlas-update-BECHA.pdf
Vesna asked for attendees' opinions on a number of different things, including the possibility of enabling WiFi measurements on RIPE Atlas probes, the possibility of developing a virtual probe, having third-party security audits done for RIPE Atlas, and offering OpenIPMap as a service. She said there wasn't time during her presentation to discuss all these topics, but encouraged everyone to speak to her or another RIPE NCC staff member about these topics and to give their feedback.
However, she did ask for discussion and feedback during the session about the possibility of enabling WiFi measurements on RIPE Atlas probes. Robert Kisteleki, RIPE NCC, said that 100 people had so far completed the poll about this question on the accompanying article on RIPE Labs, and encouraged everyone in attendance to do the same.
Daniel Karrenberg, RIPE NCC, clarified that the proposal is not simply to switch on the WiFi capabilities of the probes and allow them to sniff around, but that the proposal is to look at specific SSIDs of interest.
Vesna added that there are logistical issues to consider as well, such as whether two types of probes will have to be maintained for those who do not want to support WiFi measurements.
Christian asked whether the results of the RIPE Labs poll that was mentioned, along with the comments, would be published on the MAT Working Group mailing list, and Vesna responded that they would be.
There was no further discussion.
Sascha Bleidner, DE-CIX Management
This presentation is available online:
https://ripe71.ripe.net/presentations/87-hackathon_winning_project.pdf
There were no questions.
Christian asked for feedback about the content again, particularly because there were some math-heavy presentations this time and he said he and Nina were interested in knowing whether the content was at the right level for everyone.
Christian thanked everyone for coming and closed the session.