This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] Protocol/Technology testing?
- Previous message (by thread): [atlas] Protocol/Technology testing?
- Next message (by thread): [atlas] Protocol/Technology testing?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald Bonica
rbonica at juniper.net
Tue Feb 14 00:36:00 CET 2012
Folks, Considering Daniel's initial question, I don't think that an extension to ICMP will help. Most probably, the solution is for ATLAS nodes to send a more diverse mix of traffic (ICMP, HTTP, HTTPS IPSEC) and report results. While discussion of RFC 4884 and draft-shen was interesting, it doesn't solve Daniel's problem. Ron > -----Original Message----- > From: Fred Baker [mailto:fred at cisco.com] > Sent: Sunday, February 12, 2012 10:22 PM > To: Carlos Pignataro; Dan.Tappan at gmail.com; derhwagan at yahoo.com; Ronald > Bonica > Cc: ripe-atlas at ripe.net; Daniel AJ Sokolov > Subject: Re: [atlas] Protocol/Technology testing? > > Question for you: > > RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, > but as I read it doesn't permit the use of that structure with the Echo > Request or Reply. It seems like RFC 4884 would help in this context. > > For example, if Atlas Probes and their servers use NTP to synchronize > time, an Echo Request could contain the time the message was sent, and > the service could deduce one-way delay. The response could similarly > include a timestamp, the probe could calculate one-way delay, and > report the time and delta-time of that response in its next request. > Additionally, the service could command a probe to additionally > traceroute to another probe, and the probe could later report its > experience. > > What would it take to facilitate the use of RFC 4884 extensions with > ICMP/ICMPv6? > > > On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote: > > > Hello, > > > > Are there any plans to extend the Atlas probe's functionality from > simple Pings to more sophisticated testing? > > > > For example: > > Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and > with which parameters? > > Is encryption available (https, ssh, starttls, etc.)? > > > > Some countries and/or ISPs restrict what users can do. > > > > Currently, Iran is inhibiting all encrypted international connection. > For the users on the ground this is horrible - no gmail, no yahoo, no > online banking, no Tor network - no proivacy! > > > > Yet on the Atlas network everything seems to be fine, as pings still > work. (However, only one of the six probes is online, the rest has been > offline for weeks. And the one that is online was offline for weeks > until a few days ago. I'm not sure what the issue is there.) > > > > It would be good to know if some protocols are not available in a > certain jurisdiction. Of course, such tests could be done at a much > lower rate than Pings - some maybe every hour, others every couple of > hours. > > > > Then again, the probes might not be mighty enough? > > > > BR > > Daniel AJ > > > > -- > > Follow me on twitter @newstik http://twitter.com/newstik > >
- Previous message (by thread): [atlas] Protocol/Technology testing?
- Next message (by thread): [atlas] Protocol/Technology testing?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]