GENI的很多需求都是相互作用的。例如，一个广泛的部署自然能支持更多的用户访问，同时使GENI具有可扩展性（这样它就可以支持新的技术），也是与对联合的支持（这样新的群体和伙伴就可以增加资源到GENI当中）相一致的。

另一方面，不同类型的试验对这些需求的要求是不一样的，同理，这些需求也有不同的内在压力。这一节讲述一些压力，并且对怎样解决这些冲突提供指导。

可切片性与保真性

可切片性与保真性之间的平衡是GENI面临的最根本挑战之一。

对底层硬件的虚拟化允许众多的研究人员共享一套资源，并且能通过一个单独的物理硬件综合出多种及(或)更高级功能的虚拟环境，来提高灵活性。虚拟化有两个潜在的局限性：第一，一个试验依然有可能会影响另一个试验；第二，它潜藏了底层硬件的某些能力和属性。相比所有资源被一个人所有的情况，两者都降低了设施的保真度。

另外，虚拟化并不意味着每个slice都能公平地享有可用资源，因此就导致了不可预测的性能。一个准入控制机制能限制任一时间内活动slice个数，而且可以对某些slice做资源隔离。当然相互影响的可能性依然存在。表面上看，这种特殊的冲突很容易被解决——GENI应该在slice之间提供强壮的隔离，以及技术上允许的最低程度的虚拟化。现有的任何组件可能都不能提供这种预期的虚拟化，但在GENI的生存期内，不断地增强虚拟化技术的艺术性也是一个目标。更高级别的抽象可以为那些不愿暴露给低层细节的试验而保留，但虚拟化应该尽其所能地降“低”。

然而，有些人会争辩说，哪怕一点点的虚拟化都显得多余，认为研究需要访问“纯本质”。这可能是因为需要对某些专门组件功能的访问，或者因为虚拟化引入了太多时序测量的不可预测性。当然，也有一些资源是不能被虚拟化的。GENI并不排除将纯的硬件元素分配给一些slice的可能性——正如前一节所说，分区是另一种slice的实现方式——但是那样做是需要代价的。

在时间上分割资源，意味着资源不能维护一个真实的用户负载，因此限制了它对分布式研究的正确性。GENI资源的某些部分可以用这种方式共享，只要有充足的资源去支持分布式研究。如前面提到的，即使引入虚拟化，也需要用一个准入控制机制，限制任意给定时间活动的slice个数，类似基于时间的资源分割。

在空间上分割资源，意味着只有有限的研究者可以将给定的资源包含在他们的slice中。这对于某些不容易被虚拟化的高成本的资源是必要的。在这种情况下，研究群体要么区分他们研究内容的先后次序，或者寻找方法将他们的多种试验系统综合到少数综合的系统当中。我们设想会有上千的研究人员共享GENI，而我们可能看到只有几十个研究项目用这种方法共享访问任何高成本/非虚拟化的资源。

需要一个切分资源的GENI政策技术委员会来区分资源分配的先后顺序。

通用性和保真性

将GENI设计得具有通用性（可编程），可能会与卓越的保真性能相左。例如，一个研究人员为了真实地评估一项新的功能或者协议，可能需要用一个商业的或者功能专一的硬件实现来试验。然而在实践中，这样的实现很可能提供有限的接口而不是通用的可编程性。这样的设施，只对很少一部分试验具有极好的保真性，但对更广大的研究群体就显得缺少价值。从另一个角度来说，一个开源的、基于软件的、对相同功能或者协议的实现，可以运行在一个可被其它试验共享的通用组件上，只是没有了专有实现所拥有的性能和保真性。

显然，出于优势和利益考虑而为有限的研究人员采用特殊用途的组件也是有可能的，当然，我们也希望牺牲一定的保真性来支持一个通用的、服务范围更宽的研究设施。我们同样呼吁更多的狭隘定义的群体能将他们的特殊用途组件连接到GENI上来，以供感兴趣的研究人员使用。

简易性使通用性和保真性产生矛盾：研究人员希望在一个足够低级别的抽象层面上工作，这样，重要的系统细节就不会被隐藏；但同时，他们却不希望在那样的低抽象级别上工作，因为他们需要重新创造（对他们说）不感兴趣的软件层，来建立一个允许他们解决研究问题的环境。这确实是GENI的机会——它应该支持多级别的抽象，而且在一段时间内，为通用功能建立起一套共享代码。研究人员可以在任何一个最适合他们的抽象层上展开工作。

体系结构设计和技术开发

我们期望那些希望用GENI来测试和评价新的网络技术的研究人员，和那些希望评价新的（其它的）体系结构设计的研究人员，能考虑到新技术的能力。前者专注于单个组件，而后者应该有一个更全面的（端到端）的视角。GENI的政策是让那些利用了这个多样化的硬件资源的体系结构研究（这个定义是宽泛的）得到帮助。这是因为，没有任何一项个人的技术，在被证实可以在某个场景下为真实用户所用之前，得到充分认证，但同时这也是因为我们对开发包容多样化技术的其它体系结构感兴趣。

然而我们要说明，组件的开发者在端到端的体系结构背景下，通过GENI产生的真实负载来评估他们的技术也是有价值的。GENI允许这样的技术在成熟到足以支持GENI用户的时候插入GENI设施，但我们期望早期的技术开发（包括软硬件）在GENI之外进行。（当然作为一种过渡方式，新技术也可以在早期被GENI的小块区域采用。）为了成功地将一个新组件加入GENI,它将需要支持管理框架定义的接口，具备充分的可编程性以便为研究人员提供必要的灵活性，以及在可能的范围内（参见上面的讨论）被多个slice共享。