On 02/12/2012 10:22 PM, Fred Baker wrote:

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?

It's been 5 years since I thought about any of this but I think the way to parse the text in section 4 is that the ECHO Request and Reply messages fall into the category of:

   Many ICMP messages are extensible as currently defined.  Protocol
   designers can extend ICMP messages by simply appending fields or data
   structures to them.

I _think_ the idea was that the existing <Data> field in the ECHO messages could be replaced with an extension structure, which would be validated using the checksum. I don't know why this wasn't spelled out more explicitly, since technically responding to or updating the extension would be in violation of the text :

The data received in the echo message must be returned in the echo
      reply message.

in 792
or

 Data           The data from the invoking Echo Request message.

in 4443

Maybe because changing that behavior would be beyond the scope of 4884.



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