Targeted Stretched Farm Support
SharePoint supports a 1ms/1Gbps response time between SharePoint and SQL Server. Not all Service Applications require this level of latency. It would be great if the PG could release specific numbers for specific Service Applications (e.g. UPA must be 1ms, Word Automation Services 100ms, and so forth) or allow for variance for latency support, e.g. 1ms - 15ms fully supported.
Scott Brickey commented
@Neil: What about a stretched RESOURCE farm?
Since there aren't any requirements about RESOURCE FARM latency, the WFE to Service App communication wouldn't necessarily be subject to the same low latency requirements that you mention.
Or, perhaps, as a feature request: failover resource farms... replication of data between the resource farms (could be as simple as log shipping)... then the consuming farms could simply define one as primary and another as failover?
The challenge with this idea is that some of the most latency sensitive service applications and batch processing jobs (timer jobs) require very low latency. To produce specific latency thresholds actually makes little sense when intra farm communication of 1ms is a requirement not just for SharePoint to SQL responsiveness but for communication between SharePoint servers as well. For example. If you were to deploy a stretch farm for DR reasons across two datacentres there is a very high likelihood of that farm having search enabled. Search requires very low latency between replicas within a partition and so if you have replicas from the same partition stretched across a high (ish) latent like you are in a bad state instantly. In this scenario it makes no sense to consider higher latency for UPA because you require low latency regardless.
The only scenario when a higher latency could possibly be considered is if a farm was operating with zero components needing low latency. Not something we are likely to come across although I would like to hear it if you have a scenario that fits this case.