anchor.diff:  
   ### <a id="config-by-instance-group"></a>Consistency Behavior can vary by Instance Group
   
  -The Gorouter can [validate app instance identity using TLS](#consistency-with-tls) only when Diego Cells are configured appropriately. As this configuration is scoped to an instance group of Cells, some Cells (such as in an [Isolation Segment](../adminguide/isolation-segments.html)) can be configured to receive TLS requests from the Gorouter and others plain text [without validation of instance identity](#without-tls). This behavior can be
  -
  -Validation of app instance identity using TLS is supported for Linux Cells only. Support for Windows Cells may be added later. The Gorouter forwards requests to Windows apps over plain text and prunes based on route TTL.
  +Gorouter can [validate app instance identity using TLS](#consistency-with-tls) only when Diego Cells are configured appropriately. As this configuration is scoped to an instance group of Cells, some Cells (such as in an [Isolation Segment](../adminguide/isolation-segments.html)) can be configured to receive TLS requests from Gorouter and others plain text [without validation of instance identity](#without-tls). This behavior can be
  +
  +Validation of app instance identity using TLS is supported for Linux Cells only. Support for Windows Cells may be added later. Gorouter forwards requests to Windows apps over plain text and prunes based on route TTL.
   
   <% end %>
   
   ## <a id="transparent"></a>Transparent Retries
   
  -If the Gorouter cannot establish a TCP connection with a selected application instance, the Gorouter considers the instance ineligible for requests for 30 seconds, and the Gorouter transparently attempts to connect to another application instance. Once the Gorouter has established a TCP connection with an application instance, the Gorouter forwards the HTTP request.
  -
  -See the <a href="#round-robin">Round-Robin Load Balancing</a> section below for more information about how the Gorouter forwards requests to application instances.
  +If Gorouter cannot establish a TCP connection with a selected application instance, Gorouter considers the instance ineligible for requests for 30 seconds and transparently attempts to connect to another application instance. Once Gorouter has established a TCP connection with an application instance, Gorouter forwards the HTTP request.
  +
  +See the <a href="#round-robin">Round-Robin Load Balancing</a> section below for more information about how Gorouter forwards requests to application instances.
   
   ## <a id="round-robin"></a>Round-Robin Load Balancing
   
  -The Gorouter uses the round-robin algorithm for load balancing incoming requests to application instances. The Gorouter maintains a dynamically updated list of application instances for each route, and forwards each request for a given route to the next application instance in the list.
  +Gorouter uses the round-robin algorithm for load balancing incoming requests to application instances. Gorouter maintains a dynamically updated list of application instances for each route, and forwards each request for a given route to the next application instance in the list.
   
   ## <a id="sockets"></a>WebSockets
   
  -WebSockets is a protocol providing bi-directional communication over a single, long-lived TCP connection, commonly implemented by web clients and servers. WebSockets are initiated through HTTP as an upgrade request. The Gorouter supports this upgrade handshake, and holds the TCP connection open with the selected application instance. <%= vars.port_limitations_1 %>
  +WebSockets is a protocol providing bi-directional communication over a single, long-lived TCP connection, commonly implemented by web clients and servers. WebSockets are initiated through HTTP as an upgrade request. Gorouter supports this upgrade handshake, and holds the TCP connection open with the selected application instance. <%= vars.port_limitations_1 %>
   
   ## <a id="sessions"></a>Session Affinity
   
  -The Gorouter supports session affinity, or _sticky sessions_, for incoming HTTP requests to compatible apps.
  +Gorouter supports session affinity, or _sticky sessions_, for incoming HTTP requests to compatible apps.
   
   With sticky sessions, when multiple instances of an app are running on CF, requests from a particular client always reach the same app instance. This allows apps to store session data specific to a user session.
   
  
positive.code: 
  ### <a id="consistency-without-tls"></a>Without TLS Enabled
  
  In this mode, the Diego Route Emitters on each cell send route registration messages that include instructions for the Gorouter to send unencrypted requests to the app instance. If the Gorouter does not receive an update for the route within the time-to-live (TTL) interval, the route is pruned from the Gorouter's routing table. See [TLS to Apps and Other Back-End Services](#tls-to-back-end) for details.
  
  This pruning method was developed before the alternative was available.
  
  
negative.code: 
  * On subsequent requests, the client must provide both the `JSESSIONID` and `VCAP_ID` cookies.
  
  The CF routing tier uses the `VCAP_ID` cookie to forward client requests to the same app instance every time. The `JSESSIONID` cookie is forwarded to the app instance to enable session continuity. If the app instance identified by the `VCAP_ID` crashes, Gorouter attempts to route the request to a different instance of the app. If Gorouter finds a healthy instance of the app, it initiates a new sticky session.
  
  <p class="note"><strong>Note</strong>: CF does not persist or replicate HTTP session data across app instances. If an app instance crashes or is stopped, session data for that instance is lost. If you require session data to persist across crashed or stopped instances, or to be shared by all instances of an app, store session data in a CF marketplace service that offers data persistence.</p>
  
  ## <a id="keepalive"></a>Keepalive Connections
  
  ### From Front-End Clients
  
  Gorouter supports keepalive connections from clients and does not close the TCP connection with clients immediately after returning an HTTP response. Clients are responsible for closing these connections.
  
  ### To Back-End Servers
  
  If keepalive connections are disabled, Gorouter closes the TCP connection with an app instance or system component after receiving an HTTP response.
  
  If keepalive connections are enabled, Gorouter maintains established TCP connections to back ends. Gorouter supports up to 100 idle connections to each back end:
  
  * If an idle connection exists for a given back end, Gorouter reuses it to route subsequent requests.
  * If no idle connection exists for this back end, Gorouter creates a new connection.
  
  <% if vars.product_name.include? "CF" %> <%= vars.keepalive %> <% else %> <% end %>
  