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/[email protected]/
[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 ]
Dan Tappan
dan.tappan at gmail.com
Mon Feb 13 14:15:25 CET 2012
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 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/ripe-atlas/attachments/20120213/a9c732ea/attachment.html>
- Previous message (by thread): [atlas] Protocol/Technology testing?
- Next message (by thread): [atlas] Protocol/Technology testing?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]