diff --git a/source/core/sharded-cluster-components.txt b/source/core/sharded-cluster-components.txt
index 877d36f24aa..5b0cc9cff92 100644
--- a/source/core/sharded-cluster-components.txt
+++ b/source/core/sharded-cluster-components.txt
@@ -56,16 +56,13 @@ each application server. Deploying one :program:`mongos` router on each
 application server reduces network latency between the application and
 the router.
 
-Alternatively, you can place a :program:`mongos` router on each shard
-primary. This approach also reduces network latency between the
-application and the router: applications use a :term:`connection
-string` listing all the hostnames of each shard primary. The MongoDB
-driver then determines the network latency for each :program:`mongos`
-and load balances randomly across the routers that fall within a set
-:ref:`latency window <selection-discovery-options>`. Ensure that the
-server hosting the shard primary and :program:`mongos` router has
-sufficient capacity to accommodate the extra CPU and memory
-requirements.
+Alternatively, you can place a :program:`mongos` router on dedicated servers.
+Large deployments benefit from this approach by reducing the number of active
+connections between many application servers and :program:`mongod`. Having the
+intermediary level also allows :program:`mongos` to have a large memory
+footprint without impacting the application servers. It is possible to 
+use primary shards to host :program:`mongos` routers but be aware that memory
+contention may become an issue on large deployments.
 
 There is no limit to the number of :program:`mongos` routers you can
 have in a deployment. However, as :program:`mongos` routers communicate