INFORMATION SYSTEMS TECHNICAL ADVISORY COMMITTEE (ISTAC)

January 26, 2011 - 9:00 AM to 4:00 PM

SPAWAR, Bldg. 33 Cloud Room, San Diego CA

MINUTES OF MEETING

Committee Title:         Information Systems Technical Advisory Committee (ISTAC)

Date:                           November 7-8, 2012

Time:                           November 7th from 9:00 AM to 4:20 PM
                                                November 8th from 9:05 AM to 12:55 PM

Location:                     November 7th in Room 3884, HCHB
                                                November 8th in Room 3884, HCHB

Agenda Item Presentations/Discussions:

PUBLIC SESSION (November 7, 2012)

The meeting opened at 9:00 AM.  Approximately 27 people were in attendance.

• Opening:  Jonathan Wise opened the meeting with introductions and request for comments from the public.  There were no public comments.

• Working Group Reports: Key points from the Working Group reports were:

Cat 3A (reported by Jonathan Wise): This group has submitted several Wassenaar proposals for 2013; the complete list will be presented later today. Additionally, modular instruments and the associated the export control issues have been identified as an emerging topic for study in 2013.

Cat 3B (reported by Joel Cook): This group has submitted a Wassenaar proposal for 2013 to delete the controls on dry etch (3B1c).

Cat 4 (reported by Mark Renfeld): This group has submitted two Wassenaar proposals for 2013; these will be presented later today. This group has also identified an issue with the FNR review requirement in License Exception APP.

Cat 5p1 (reported by Jonathan Wise): This group will be looking at the 5E1c1 technology control in 2013. The issue of the ENC control threshold for satellite modems remains open, awaiting feedback from BIS.

Cat 5p2 (reported by Roz Thomsen): This group has submitted two Wassenaar proposals for 2013, pertaining to OAM and to specially designed, and remains interested in working on a mass-market software decontrol. Additionally, this group will be reviewing the 740.17(b)(2) criteria with regard to satellite applications.

• APP, Aggregation & Performance in Cat 4:  Henry Brandt presented an informational overview on APP, aggregation and performance.
  • The starting point of this presentation is that Note 6 defines when to aggregate, and that APP is intended to be a method for rank-ordering performance. However, “aggregation” and “performance” are undefined terms.
  • What matters most is application turnaround time, but this can be thought of in two ways: throughput (number of jobs completed within a given time, i.e., “capacity” systems) or turnaround time (how fast can a single application be completed, i.e., “capability” systems).
  • Joel Cook asked whether the CPU is a limiting factor. Henry responded that it might not be, but for practical simplicity once simply chooses floating point performance as the relevant metric.
  • Matt Jones asked about parallel processing. Henry explained that this is context-specific. He cited internet searching as an easily parallelizable task, but noted that this is so because it is actually many independent small tasks. By contrast, other applications may have time-critical components (e.g., for weather forecasting, one generally wants a result now, not after the weather event has occurred).
  • Henry suggests that the national security concerns underlying the 4A3 controls pertain to “capability” systems. The reason that throughput does not matter to APP is substitution: many small applications are not equivalent to one large application; the applications of interest do not produce useful results in a timely on PC clusters.
  • From this, it can be understood that “performance” in Cat 4 means the execution speed, in double-precision flops, of a single application running on a full system (the unwritten assumption is that all systems implement the IEEE-754 floating point standard). This is obtained by harnessing all the processors (cores) in the computer such that they each execute a portion of a single application in a single application in a tightly-synchronized manner.
  • One can gain insight into why APP aggregates only double-precision floating point by performing a thought experiment: Could one easily circumvent the Cat 4 controls on HPC?  In theory, one could develop a 63-bit floating-point architecture that has massive capability but an APP of zero.  In practice, however, this would have little benefit because it would not be financially viable, because existing software would not run correctly on this system and this system would have huge costs for development of both the hardware and the software. The conclusion is that shorter word-length architectures lack sufficient precision to handle the applications of interest, and for that reason they are excluded from APP.
  • Regarding aggregation, the APP formula and associated Notes are intentionally imprecise, intended to be flexible to accommodate new architectures and new interconnect standards.
  • Existing guidance on APP is primarily the “Practitioner’s Guide to APP” (http://www.bis.doc.gov/hpcs/app-wtpractitionersguidefeb22with-cover.pdf).
  • The philosophical underpinnings of aggregation make sense: 1) The regulations implicitly acknowledge the uncontrollability of commodity clusters. 2) The local-area network hardware (e.g., Ethernet or InfiniBand) used to build these clusters is not “specially designed” for aggregation. 3) Developing a proprietary interconnect is expensive.
  • Greg Tarr asked whether it would be possible to list the HPC systems that are controlled. Henry responded that it is possible to do that at any given time, but the list of controlled systems evolves with time and thus cannot form the basis of a viable approach to export control.
  • It is necessary to aggregate in the following cases: 1) All cores in a microprocessor sharing memory or a proprietary interconnect; 2) All microprocessors within a computer/node sharing memory or a proprietary interconnect; 3) All nodes in a system using a proprietary interconnect; 4) But not if using LANs (e.g., Ethernet) or standard I/O adapters (e.g., InfiniBand).
  • Henry summarized that current practice seems to be working well. Industry appears to apply the regulations in a fair and consistent manner, and questions about interpretations are rare, which suggests that the control text is aging well in the face of evolving architectures.
  • Matt Jones asked how this applies to the 4E technology controls. Henry responded that there is little export licensing burden for hardware, but that the deemed export burden is relatively larger because the control thresholds tend to be lower for technology than for hardware and development/design occurs several years before hardware is available commercially. David Lindsay concurred with this viewpoint.
  • Roz Thomsen asked whether there are any issues with the weighting factors (0.9 for vector processors and 0.3 for non-vector processors). Henry responded that there are no issues or concerns with the interpretation of APP: with the exception of some NEC machines which use the 0.9 factor, all other machines use the 0.3 factor.  David Lindsay added that “vector processor” is tightly defined such that microprocessors fail to meet the control thresholds (because they are far below 64 double-precision words).
  • Because this presentation was informational, no specific follow-up actions were needed.

• Industry Submissions for 2013 Wassenaar Proposals:  Jonathan Wise presented an overview of proposals that industry has submitted to BIS, for consideration in the 2013 Wassenaar cycle.
  • 3A1a5: Update the control thresholds for ADC to reflect the progress of technology since the last update in 2010. Refer to Dave Robertson’s presentation in the minutes of the July 2012 ISTAC meeting.
  • 3A1a2-3A1a4: Delete the controls on various types of magnetic tape instrumentation recorders, because these are a sunset technology, being replaced by hard-drive recorders.
  • 3A2c1:  Delete the control on Resolution Bandwidth (RBW).   This parameter was established as the inverse of 100 ns pulse in 3a2d1, but it is now believed that reasoning is technically sound.
  • 3A2d1:  Editorial correction to the definition of pulse. This would update “pulse” to “pulse modulated signal”, for improved clarity
  • 3A2d4: Update to control formulae for phase noise.  This would update the controls to remove the step-change at 10 kHz offset and replace it with an inflection point at 5 kHz offset, so that the shape of the lines describing control thresholds more closely match the shape of phase noise curves of actual instruments.
  • 3B1c: Delete the control on dry etch. These tools are non-deterministic and thus not controllable under the standard formulations of control language.
  • 3D3: Delete the control on physics-based software, as the subject software is believed not to exist and unlikely to exist in the future. Refer to Larry Disenhof’s presentation in the minutes of the July 2012 ISTAC meeting.
  • 3E2: Delete the control on microprocessor technology. This is believed to be widely disseminated such that control is no longer feasible.
  • 4A3: Deletion of all of 4A3, in recognition of the fact that high-performance computing is now ubiquitous and no longer susceptible to control. Instead of on HPC hardware, control should be on pertinent software. The Cat 4 Working Group recognizes that this likely to encounter political resistance, and for that reason believes that it is important to start the discussion now.
  • 4A3b/4E1b: As a backup, in case 4A3 deletion cannot be agreed, raise the APP control -thresholds to account for continuing technology developments.
  • 5p2: Decontrol Note for OAM products
  • 5p2: Clarification of controls, to eliminate or replace the term “specially designed”

• Wassenaar Proposal for 4A3 Deletion: Henry Brandt returned with an industry proposal to delete 4A3 and correspondingly 4D1, 4D2 and 4E1b (although retaining control on 4A1 extreme temperature and rad-hard computers). The essential rationale is that the usual bases for control (Wassenaar criteria for inclusion on the dual-use list) no longer apply. Key points were:
  • Nearly all HPCs are now massively parallel designs, and clusters are the dominant HPC system configuration (the sole exception being NEC, which continues to produce some vector supercomputers).
  • An analogy for HPC can be made to drag bikes (number of engines in the drag bike to number of processors in the supercomputer): both are fast, largely hand-built, have relatively few people involved from end-to-end, and have a small customer set.
  • Modern HPCs are comprised of the following: 1) Processors, which are effectively decontrolled from Cat 3; 2) Memory, which is effectively decontrolled from Cat 3; 3) Interconnects, for which proprietary designs are fading away and instead standards are dominating, and additionally the functionality is moving inboard to the microprocessor; 4) Storage, which is effectively decontrolled from Cat 4; 5) Advanced packaging, cooling and power management, all of which are effectively decontrolled; and 6) software, for which operating systems, tools, middleware and most applications are decontrolled (although the national security applications of concern are controlled separately and, in any case, are not dual-use).
  • The factor that makes an HPC controlled is the interconnect.  Controls apply to computers having APP > 3 WT, but the vast majority of HPC are clusters having standard (decontrolled) interconnects. Thus, controls apply only to the small (and diminishing) number of HPC that have proprietary interconnects: Proprietary Interconnects are the basis for export controls on HPC, all other items have been decontrolled. In the drag-bike analogy, the interconnects are the drive belts.
  • But the technology trends for interconnects are such that they are becoming increasingly rare and that they are also being moved into the microprocessor die. That is, Cat 4 interconnection is becoming an invisible technology buried inside Cat 3 microprocessors.
  • Jack Edwards asked what are the implications of interconnection moving onto the microprocessor die. Henry elaborated that the HPC industry just becomes system integrators; they have already stopped designing special microprocessors (RISC, etc.).
  • Interconnect no longer provides the bright line differentiation that it once did. The performance gap between proprietary and commercial interconnect is steadily decreasing. The TOP500 illustrates that Linpack efficiencies are comparable between systems with proprietary and commercial interconnects.
  • In actual practice, all major application spaces (e.g., seismic, fluid dynamics, crash simulation, financial services, life sciences, government laboratories) have migrated from vector to RISC constellation and finally to X86 massively-parallel clusters. Even the weather/climate applications, which had been thought to be extremely difficult to migrate to clusters, are now beginning that migration.
  • The conclusion is that the 4A3 controls on HPC are no longer justified. A shrinking number of products are subject to controls. Equivalent products (decontrolled clusters) now dominate the marketplace. The feature responsible for differentiating controlled products (i.e., interconnects) is becoming insufficient for this purpose. The case for hardware performance as a proxy for military utility is obsolete. Thus, controls on digital computers should be eliminated as they have already been eliminated on nearly all the components/assemblies required to create a digital computer.
  • Finally, a supplemental comment on Cloud Computing: the ISTAC should monitor public-cloud computing for HPC. Currently, such capabilities are limited to “embarrassingly parallel” applications, but we can expect to see increased emphasis in this area.
  • Actions: The Cat 4 Working Group will discuss this proposal with BIS.

• Trade in Security Exploits:  Christopher Soghoian of the American Civil Liberties Union spoke on the implication and issues of trade in “zero-day” exploits (i.e., security vulnerabilities that have not been disclosed publicly). The essence of the issue is that 1) the concept of “zero-day” exploits is not widely understood by that general public community of computer users; 2) trade in “zero-day” exploits is currently unregulated; and 3) there are multiple and competing interests and equities in the matter.
  • The underlying technical issue is that computer malware (viruses and the like) have two parts: a payload and a transmission vector (vulnerability). The underlying policy issue is handling of vulnerabilities once they are discovered.
  • Among the interest and equities that may affect the underlying policy are: 1) Publicizing of vulnerabilities quickly and widely, so that affected users may take steps to protect themselves and simultaneously to provide strong incentive to manufacturers to issue the necessary security patches. 2) Provision of compensation to the discoverers of vulnerabilities and the questions of what is appropriate compensation and who should pay it. 3) Purchase of vulnerabilities by governments for use in cyber-attacks against adversaries.
  • Regulation of trade in “zero-day” poses challenges, simply in determining an appropriate mechanism. Export control seems unlikely to be effective. At this stage, reporting for the purpose of informing policy-makers about the scope and nature of the market might be sufficient.
  • The ACLU currently has no official position on the matter of “zero-day” exploits.
  • Because this presentation was informational, no specific follow-up actions were needed. However, this presentation may help inform the ISTAC’s discussions of possible future Wassenaar proposals seeking to implement new controls on “cybertools” as well as any regulatory proposals to amend Section 740.17(b)(2)(i)(F) of the EAR.

• The open session was adjourned at 2:00pm.