Frequently Asked Questions
Q: What are the components of a Science DMZ?
A Science DMZ consists of 3 key components, all of which are required:
Q: What is a DTN?
Q: What about security?
We have a separate page that discusses firewalls and other security issues.
Q: Can I have a firewall in my DMZ?
Typically firewalls add no value over router ACLs in a Science DMZ, and often are a performance bottleneck. Router ACLs, combined with a high performance IDS are the better choice.
Q: Is support for virtual circuits required?
No, but virtual circuits can be helpful in a number of ways. Using circuits you can enforce bandwidth guarantees, and provide a means of supporting protocols and technologies that rely on layer-2 reach-ability.
Note that it is often the case that perimeter firewalls cannot effectively support virtual circuits, and so the only way for a site to effectively support virtual circuits is to deploy a Science DMZ.
Q: Why is perfSONAR required?
Packet loss is the number one killer of network performance. An example of this is found here. Therefore it is very important to continuously monitor your science DMZ for packet loss. The only reliable way to do this is with active probes. perfSONAR is the only easy to use open source tool we are aware of that lets you monitor a set of paths for packet loss.
Q: What storage model is appropriate for a DTN?
This depends on what is available at your site. DTN nodes at large sites are often connected to an Infiniband-based storage cloud running Lustre or GPFS. Some mount remote disk over NFS. Others just have a large RAID array, and data is staged to the DTN before it is copied across the WAN.
Q: What about security for my storage infrastructure?
This depends on your site, and your site's security model. Some sites allow DTNs full read-write access to the filesystem and employ the same access controls on the DTNs that they employ on their other systems. In other cases, the DTN mounts the central filesystem read-only - this can allow for reading data at high speed, but writing to the shared disk might take a slower path into the site.
Q: I noticed you recommend network devices with large buffers in a Science DMZ. Won't this make "buffer bloat" worse?
Buffer bloat is a completely different problem space, and mainly effects low speed links. Buffer bloat is caused by queues that are very deep in relation to their drain rate, and where the ingress rate is much higher than the egress rate (e.g. a few seconds of buffer on a device with an ingress of 100Mbps to 1Gbps and an egress rate of 1-2Mbps).
See the section on router tuning for more information on packet fan-in issues for high-bandwidth flows.
Q: What is the role of OpenFlow in a Science DMZ?
OpenFlow is a very interesting future option for a Science DMZ. It could potentially be used to help create an end-to-end layer 2 path, or to dynamically update security ACLs. At this point we feel that OpenFlow is too new for a production Science DMZ deployment, but recommend that any new network equipment purchased support OpenFlow to be able to take advantage of new OpenFlow capabilities in the future.
Q: I'm giving a talk that mentions the concept of a Science DMZ. Is there a concise 1 slide summary I can use?
Yes, available here!
Q: Where did the term Science DMZ come from?
The term "Science DMZ" was coined by Eli Dart of ESnet in a network performance discussion with Brent Draney of NERSC and Paul Henderson of PPPL at an ESCC meeting in 2009. The first public talk with term Science DMZ was given at the summer 2010 ESCC meeting by Eli Dart.
Contact email@example.com if you have updates or corrections for information on fasterdata.es.net