Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] Current status of PS in Amazon Cloud services

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] Current status of PS in Amazon Cloud services


Chronological Thread 
  • From: Mark Feit <>
  • To: Casey Russell <>, "" <>
  • Subject: Re: [perfsonar-user] Current status of PS in Amazon Cloud services
  • Date: Fri, 22 Feb 2019 18:45:30 +0000

Casey Russell writes:

 

The last time I see the question addressed was two years ago in 2017 when it was acknowled that there were a host of problems trying to deploy a PS node in the amazon cloud.  It appears the problems were mostly surrounding the NAT issues.  Has there been any progress made in the intervening time?  Is anyone deploying a set of PS tools in Amazon Cloud services to monitor their new Cloud Connect connectivity or something similar?  If so, do you have a roadmap or template for doing so?

 

Things are much the same.

 

NAT isn’t difficult to deal with for tests like TCP throughput, where you can do reverse testing to dodge the translation.  It’s a lot stickier for UDP throughput, latency and RTT, where you can do tests from the behind the NAT to the outside, but anything you can do the other way won’t traverse it and there isn’t necessarily a server available to play the “other end” role.  We’ve discussed things like UDP hole punching, but the number of variables would make it difficult to support.  The only other way around it is to have public IPs.

 

The harder problem to overcome is the uncertainty that comes from deploying infrastructure in what’s essentially a geographically- and topologically-diverse black box.  An AWS instance in us-east-1 will materialize as one VM on one machine in one rack in one aisle in one of almost three dozen buildings in two counties in Northern Virginia.  (I live near Ashburn and drive past Amazon’s data centers often enough to have a good feel for how large and spread out their presence here is.  It’s quite something.)  Making end-to-end measurements meaningful is difficult in an environment where there’s no control over the location of one end, but that lack of control is what makes commodity computing cheap enough to be attractive.  I’ve run into researchers who install perfSONAR in a container on the same instances where their applications run and treat any measurements they get as valid for only that instance.  If I remember correctly, their institution was getting a large-enough break on network traffic that the cost of outbound throughput testing wasn’t an issue.

 

This has been mentioned before but is worth repeating:  Check the agreements you have with cloud providers before sharing the results of performance measurements involving their systems and networks.  I don’t know if it’s still true, but at least one provider forbade that.

 

Putting on my Internet2 hat for a moment:  We have internal-use-only perfSONAR nodes in the vicinity of some, but not all, of our cloud provider handoffs.  There have been discussions about adding more at those points but no solid action.  If you’re a member and consider this important to your operations, your feedback helps drive what we do.

 

HTH.

 

--Mark

 




Archive powered by MHonArc 2.6.19.

Top of Page