Are there any plans to support an HTTP UDM? Thanks -Miles
On 03.08.2012, at 08:10, Miles McCredie wrote:
Are there any plans to support an HTTP UDM?
Yes, but .... it will be very basic and definitely not be there to compete with widely available "web site testing". It will likely be very restrictive on the amount of data it fetches and the number of probes. RIPE Atlas is designed as a network level measurement tool and not an application tester. We are also somewhat concerned about consequences for our probe hosts. Consider what can happen if an atlas user causes your probe to access content that is considered inappropriate or even illegal where you live and run your probe. Considering this, it would be very useful to know what it is that you want to achieve and have a discussion on what RIPE Atlas should do. Daniel
On 8/3/12 02:37 , Daniel Karrenberg wrote:
it will be very basic and definitely not be there to compete with widely available "web site testing". It will likely be very restrictive on the amount of data it fetches and the number of probes. RIPE Atlas is designed as a network level measurement tool and not an application tester.
We are also somewhat concerned about consequences for our probe hosts. Consider what can happen if an atlas user causes your probe to access content that is considered inappropriate or even illegal where you live and run your probe. Understood.
Some thoughts: - Restrict the UDM to retrieving /robots.txt. (Generally innocuous/legal content and not too large?) - Limit the UDM to retrieving 4500 bytes or so of data and then sending a RST. (Enough data to confirm max MTU frames can be received but not enough to contain inappropriate or illegal content?) - Send a RST after receiving a SYN-ACK response. (Would be useful to allow port configuration in this case to allow tests for filtering.) Thanks -Miles
On 03.08.2012, at 17:36, Miles McCredie wrote:
On 8/3/12 02:37 , Daniel Karrenberg wrote:
it will be very basic and definitely not be there to compete with widely available "web site testing". It will likely be very restrictive on the amount of data it fetches and the number of probes. RIPE Atlas is designed as a network level measurement tool and not an application tester.
We are also somewhat concerned about consequences for our probe hosts. Consider what can happen if an atlas user causes your probe to access content that is considered inappropriate or even illegal where you live and run your probe. Understood.
Some thoughts: - Restrict the UDM to retrieving /robots.txt. (Generally innocuous/legal content and not too large?) - Limit the UDM to retrieving 4500 bytes or so of data and then sending a RST. (Enough data to confirm max MTU frames can be received but not enough to contain inappropriate or illegal content?) - Send a RST after receiving a SYN-ACK response. (Would be useful to allow port configuration in this case to allow tests for filtering.)
Thanks -Miles
In addition to those we thought about restricting to the HEAD method. This is currently our favorite. Any problems with that? Doing stuff on the TCP level is a complex thing to implement and get right, but possible. One concern remains that purely accessing a specific server/service may be regarded as inappropriate or illegal in certain places and saying "It was an Atlas probe and it only fetched robots.txt" is not going to be a viable defense. But again: what exactly are you trying to achieve/measure? Knowing that from you and others looking for HTTP UDMs would help us understand the problem space better and to propose a solution. Daniel
On 8/3/12 11:45 , Daniel Karrenberg wrote:
But again: what exactly are you trying to achieve/measure? Knowing that from you and others looking for HTTP UDMs would help us understand the problem space better and to propose a solution. My short term interest is in collecting data about the availability of <http://ipv6.msftncsi.com/ncsi.txt> which Win8 will be using to determine connectivity to the IPv6 Internet. HEAD would be useful but "GET /ncsi.txt" would be better (and smaller :-).
Longer term, I'm also interested in comparing the relative performance of IPv4 and IPv6 for dual-stack hosts and in measuring TCP port filtering. Thanks -Miles
participants (2)
-
Daniel Karrenberg -
Miles McCredie