[atlas] Protocol/Technology testing?

Hi Dan,

On 2/13/2012 8:15 AM, Dan Tappan wrote:
> 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.
> 

If I remember correctly, additionally, RFC 4884 encountered pushback
when we were trying to define an object extension at a fixed location,
and therefore we ended up needing to add a "Length" field in the ICMP
header. And since Echo / Echo Reply did not have room for a field in the
ICMP header, it was out of scope for RFC 4884. Because also RFC 4884
extended error messages that were including part of the original datagram.

Thanks,

-- Carlos.

>>
>>
>> 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
>>>
>