You're viewing an archived page. It is no longer being updated.
Wednesday, 17 October 2018, 14:00 - 15:30
WG co-Chairs: Nina Bargisen; Brian Trammell
Scribe: Matt Parker
Status: Draft
Nina opened the session and sent apologies from Brian who was unable to attend in person (due to happy circumstances in the family). Nina approved the agenda for this meeting, approved the minutes from the last meeting, introduced the Chat Monitor and Scribe from the RIPE NCC and thanked the stenographer.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2249
Jen Linkova, Google, agreed that when you perform measurements to a name the clients may go to different destination servers, which may explain some of the results and may make it difficult to draw conclusions. She commented that it would be interesting to measure clients using the same access technology accessing the same destination. Ermias explained that the number of data points measured combined with the stability of the LTE network in Finland means that the difference shouldn’t be significant.
Jen asked to go back to the slide on DNS failures and asked whether they looked for any correlation with the resolver that they were using, commenting that she was surprised to see a difference in the failure rate for domains and that perhaps it could be explained by the failure rate of different resolvers. Ermias agreed and mentioned that he displayed the results per radio technology to show that there wasn’t a large difference between, for example, LTE and UMTS.
Finally, Jen recalled that these measurements were taken five years ago and wondered about the results of the same measurements taken today. She commented that she would expect them to be quicker, especially from mobile devices to websites that support QUIC, and suggested that they might want to look at how much UDP they see now.
Sebastian Castro, InternetNZ, was interested in the client lookup and whether they were querying the same resolver, if the resolver was prime, and whether they are really measuring the lookup time from the hand-held device to the resolver. He concluded that he would approach Ermias later to discuss the methodology in more detail.
Florian Streibelt, Max Planck Institute for Informatics, challenged what they have measured on the radio technology. He asked if Ermais had any information on how the ISP was doing the backhaul for the LTE network and whether they were using fibre or traditional copper with 2Mbit. Ermias responded that he did not have any details from the network operators about the backhaul network.
Daniel Karrenberg, interested engineer, asked whether the collected information about the public IP address that the client connected from once they hit the Internet. Ermias explained that they have the IP address of the client’s device but that may be a private IP address. Daniel commented that it would be interesting to see where the measurements reached the Internet as it may highlight any differences in the backhaul.
Lee Howard, Retevia, questioned why they chose to measure over IPv4 only and didn’t include IPv6. He also asked whether they had anticipated any differences if they’d used IPv6 since there is a small body of work indicating that latency may be lower over IPv6 on mobile networks. Ermias responded that the operator was still growing their IPv6 network and that there was no IPv6 included in this study.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2250/
Robert Kisteleki, RIPE NCC, commented that it was fascinating work and that he would speak with Maxime offline about taking it further and attaching it in some way to RIPE Atlas. Robert asked Maxime if he were able to get a real-time feed, how long would it take the machinery to realise that the network is now in a different state. Maxime replied that he doesn’t have an answer to that question at this moment but that he is starting to work on that now, Robert stated that he is offering a seat for Maxime to find that out.
Giovane Moura, SIDN Labs, asked to confirm whether the delay shown in the early slides was between anchors of probes. Maxime confirmed it was between anchors. Giovane stated that he would be interested to repeat the measurements using DNSMON towards the root servers rather than ICMP because this tends to get low priority in ISPs.
Khaldun Maruf, NTT Communications, commented that it was very interesting work and that adding the dimension of AS path might make it even more valuable as a practical tool for network operators.
Cristel Pelsser, University of Strasbourg, asked whether they looked at sequences in the changes of state and whether they observed and repetition in the sequences. Maxime responded that they had not looked at that, but it would be interesting, and that they would also like to analyse the periodicity of the state changes. Cristel also commented on Robert’s question about how fast you can detect changes stating that it would be dependent on the frequency of the measurements.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2252/
Mohsen Souissi, AFNIC, asked whether he understood correctly that querying an SOA record for a zone would give the status of the zone. Tim confirmed that when changes are made to a zone the serial should be changed as well. Mohsen stated that if he changes the zone, and then when the interval asks for another record, the TTL will go the same way, so he can have as many statuses for the same zone as the number of RR sets or records that it contains. Tim agreed.
Mohsen also asked whether Tim had seen the probes going up and down and, if yes, whether he had an explanation for that. Tim confirmed that they had seen this and that the cause was the use of anycast resolvers, he suggested that using the NSID option could mitigate this impact. Mohsen commented that the NSID option doesn’t work very well with resolvers and that it is usually seen more on the authoritative side.
Mohsen also asked how they were able to determine the primary when retrieving a fresh SOA record. Tim explained that there is a field to specify the IP address of the primary. Mohsen commented that in some architectures there is a hidden primary. Tim confirmed that this can be the case, reiterated that this is a proof of concept and explained that they could use a field containing the serial to work around this issue.
Giovane Moura, SIDN Labs, mentioned that he presented some similar work on Monday and recommended that Tim take a look at it. He also commented that Tim may be over-simplifying the resolver infrastructure which may have multiple layers of resolvers and forwarders. Tim agreed and spoke about the difficulty of making measurements when the target is in a private network.
Robert Kisteleki, RIPE NCC, thanked Tim for his work and offered further RIPE Atlas credits should he need them. Robert also commented that the use of TTL 0 may be debated and suggested running the study again with more probes for a longer period of time to see if they get the same result.
Petr Špaček, CZ.NIC, also commented on the use of TTL 0, he recommended using TTL 1, 5 or 10 for future measurements to avoid issues with the resolver.
Florian Streibelt, Max Planck Institute for Informatics, mentioned that he would really like to see the results if other resource records were queried because some name servers will implement different caching for different record types.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2253/
Jen Linkova, Google, gave an example of a situation which results in low hop count but higher latency; three hops within the country and one hop across a transatlantic link. She commented that there may not be a correlation between the number of hops and the latency. Viet agreed that one hop doesn’t specifically represent a measurement in terms of distance.
Cyrill Malevanov, Selectel, commented on the lower latency for IPv4, despite longer path lengths than IPv6, and questioned whether this could be because IPv6 infrastructure is not financially critical for most organisations? Viet agreed with this conclusion stating that IPv4 topology is probably more optimized than IPv6, which has been experimental for quite some time.
Will van Gulik, AS2613, wondered if they had spotted similar ASNs in the path for IPv6 that were not cached, for instance if HE (Hurricane Electric) was appearing in the results? Viet said that he wasn’t sure but commented that they could always go back to the results to check.
Giovane Moura, SIDN Labs, commented that YouTube is announcing its addresses using Anycast meaning the same IP is announced from various locations, he asked if this was factored into the measurements. Viet replied that their methodology relied on the probes mimicking the actions of a regular user in the network and therefore assumes they will mostly reach the most local server.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2255/
Cristel Pelsser, University of Strasbourg, commented that she is also very interested in discovering multipath in Ass. She asked how they discovered the AS paths in their study and whether they were affected by load balancing at layer 3. Kevin confirmed that Cristel was describing ‘per destination load balancing’ and explained that the MDA (Multipath Detection Algorithm) was not crafted to discover destination load balancing. Although it’s worth noting that the literature suggests an extension to the MDA has been developed to handle per destination load balancing.
The presentation is available at: https://ripe77.ripe.net/archives/video/2256/
Giovane Moura, SIDN Labs, thanked Robert for the infrastructure and commented that he used it all the time. He asked about the cloud deployment and whether there was a plan to have a VM per region available. Robert confirmed this is the plan with Amazon and that they are also in discussions with other providers such as Linode, Digital Ocean etc.
Christian Teuschel, RIPE NCC, mentioned that there would be a RIPEstat Q&A session during the coffee break and that anybody interested could join at the Meet & Greet stand.
Daniel Karrenberg, interested engineer, commented that it was great to see that the products provided by the RIPE NCC are getting widespread use and that he hopes they will develop a little more into products that are useful to ISPs. Daniel encouraged all those representing ISPs to speak up in the NCC Services session (or speak to the RIPE NCC board) to let them know that they appreciate these products.
There was no further business. Nina encouraged everybody to complete the surveys and concluded the session.