Publisher Selection

When a user accesses an authorized Private App, the policy is enforced on the Netskope Cloud at the NPA Client Gateway node. The NPA Client Gateway is responsible for selecting which Publisher(s) to route a connection through.

The above diagram depicts the components for NPA traffic steering.

• Netskope Client <-> Client Gateway
• Client Gateway <-> Publisher Gateway i.e., Stitcher (Netskope New Edge)
• Publisher <-> Publisher Gateway i.e., Stitcher
• Publisher <-> Private App

The following sections cover the expected behavior when Latency-based Publisher Selection is enabled and explain the behavior without the Latency-based Publisher Selection feature, and how stickiness works.

Latency-based Publisher Selection

When the Latency-based Publisher Selection feature is enabled, NPA will choose the Publisher closest to the user from the configured pool of Publishers, based on latency.

This feature optimizes performance and provides faster access by selecting Publishers according to the latency between the NPA Gateway and the Publisher. The goal is to reduce latency from the Gateway to the Publisher by selecting the Publisher from the lowest latency bucket.

Use Cases

When the Latency-based Publisher Selection feature is enabled for a geo-distributed application (for example, Active Directory Services), it is expected that the most optimal (per latency) Publisher gets selected, thereby improving the performance and enhancing the end-user experience.

Similarly, for Application Discovery, when the scope is defined, enabling this feature ensures the most optimal publisher is chosen for end user traffic.

How does Latency-based Publisher Selection Work?

• The NPA Client Gateway to Publisher latency can be separated into two parts:
  • NPA Client Gateway to Publisher Gateway (Stitcher) latency.
  • Publisher to Publisher Gateway (Stitcher) latency
• The NPA Client Gateway will make routing decisions for new connections based on a lookup for latency from NPA Client Gateway to the Publishers.
• The latencies are recorded across predefined buckets, and the NPA Client Gateway will prefer the lowest latency route.

Individual Client Gateway to Publisher latency measurements are separated into predefined buckets of latency ranges: (below in milliseconds).

Buckets: [0, 32), [32, 64), [64, 128), [128, 256), [256, 512), [512, 1024), etc.

An algorithm will select a Publisher from the bucket with the lowest latency. For example, for a Private App defined, if we have multiple Publishers available, the Gateway will select one of the Publishers from the least latency bucket [0-32]. If none of the Publishers are available in [0-32) ms bucket, then the Gateway will try to select one of the Publishers from the [32-64) bucket and so on.

The Publishers with upper bound latency values like 32,64,128, etc. fall in the higher latency bucket. For example, a Publisher with 32ms latency will fall in the [32,64) latency bucket, and a Publisher with 64 ms latency will fall in the [64,128) latency bucket.

For example,

Publisher	Client Gateway to Publisher #n Latency
Publisher #1	10 ms (preferred route)
Publisher #2	12 ms (preferred route)
Publisher #3	42 ms
Publisher #4	42 ms

Best Practices for Latency-based Publisher Selection

• Ensure that regional Publisher instances can handle the user traffic for each region. Without the Latency-based Publisher Selection feature, users may get load distributed across Publishers in both regions. With this feature, Publisher selection becomes more predictable and proper capacity planning is needed. For example, in the diagram, users in California would connect to apps in California via Publishers in California. It is imperative that Publishers in California can handle the traffic for users in California.
  
• Netskope recommends placing Private Apps as close (low latency) to the Publisher as possible.
• Netskope recommends that you identify the apps and policies that would benefit from enabling this feature. Ideally, globally distributed app instances (such as Globally distributed AD servers) with Publishers across multiple regions should benefit from this feature. It is expected that the most optimal (per latency) Publisher gets selected.
  Without latency-based selection, it is possible that a sub-optimal Publisher may get selected.

How to Validate Latency-based Publisher Selection is Working

1. Verify that device assessment shows publisher_selection:true when the Publisher selection flag is enabled for the tenant.
   1. Check the device assessment in the npadebuglog.log on the client machine.
   2. The publisher_selection flag should be true.
   3. Here’s a sample log from a macOS machine.
2. Verify that your tenant UI shows the selected Publisher with latency details.
   1. In your Netskope tenant, go to Skope IT > Network Events.
   2. Click View Publisher Latency Details, which shows the Publisher(s) in the same latency bucket, and the latency range as well.

FAQs

I have multiple Publishers associated with a given Private App. How does NPA select a Publisher for a user?

Let’s say, we have the below scenario:

Private App	Associated Publisher
#1 Jira	Publisher #1 and Publisher #2
#2 SQL Server	Publisher #1, Publisher #3 and Publisher #4
#3 Web Server	Publisher #1, Publisher #2, Publisher #3 and Publisher #4

Let’s also assume that all publishers are connected to Netskope Cloud and that there is reachability from Publishers to the respective Private Apps.

When Latency-based Publisher Selection is Enabled

When a set of Publishers are defined within a private application, connections are load balanced across the least latency bucket Publisher pool.

Let’s say user A has access to both Private App #2 and #3.

When user A accesses Private App #2 for the first time, let’s say for Publisher #1, the latency bucket is [32,64) ms and Publishers #3 and #4 are within the latency bucket [0,32) ms. In this scenario, the NPA Gateway may randomly assign Publisher #3 as it belongs to one of the least latency bucket Publisher pools. All subsequent requests for user A and Private App #2 will go through the same Publisher #3 as long as the Publisher remains connected/active.

If the same user A tries to access Private App #3, as it is a new TCP/UDP flow, NPA Gateway will retrieve the active Publisher list for Private App #3, and choose a Publisher from the least latency bucket pool, and that could happen to be Publisher #1.

When user B accesses Private App #2 for the first time, their traffic might be steered through Publisher #1 as it may be one of the Publishers in the least latency bucket for user B. Similarly, all subsequent requests for user B and Private App #2 will go through the same Publisher #1.

It is expected that there is a Publisher stickiness maintained for a user per Private App. The stickiness for a user per Private App is maintained until a new SRP is obtained by the Client or tunnel reconnect, or as long as a Publisher remains connected/active.

When Latency-based Publisher Selection is not Enabled

When a set of Publishers are defined within a Private App, connections are load balanced across the different Publishers.

Let’s say user A has access to both Private App #1 and #2.

When user A accesses Private App #1 for the first time, let’s say Publisher #1 is selected. All subsequent requests for user A, and Private App #1 will go through the same Publisher #1.

If the same user A tries to access Private App #2, as it is a new TCP/UDP flow, the NPA Gateway will retrieve the active Publisher list for Private App #2, and choose one of the Publishers (Publisher #1, Publisher #3, and Publisher #4).

When user B accesses Private App #1 for the first time, their traffic might be steered through Publisher #2, and not necessarily steered by Publisher #1 like for user A. Similarly, all subsequent requests for user B and Private App #1 will go through the same Publisher #2.

Similar to Latency-based Publisher Selection, it is expected that there is a Publisher stickiness maintained for a user per Private App. This stickiness is maintained until a new SRP is obtained by the Client or tunnel reconnect, or as long as a Publisher remains connected/active.

Where can I find the Publisher chosen for a session?

The Publisher chosen can be seen within Network Events. In your Netskope tenant, go to Skope IT > Network Events.