Do we have a plan to continue promoting the fast path implementment?

[Eric-Yuan]

For now, Mizar have support fast path feature which could unload flows from bouncers by packet triggered, that is awesome.

But there are still remain some issues could be promoted, for example: 1) flows that across subnets in one network or flows that forwarded according to user custom defined routes could not be unloaded
2) flows with a very low throughput or flows that last a very short period still be unloaded

If Mizar have a plan to continue promoting the fast path feature?

[zasherif]

All flows go through a direct-path (fast-path as you call it). It really does not matter if the flow has a very low throughput or lasts a very short period of time. The limitation is that we use an LRU to manage the endpoint's host. This limitation has an effect if all the endpoints on a host communicate with over 1M endpoints (outside the host). This is a very hard limit to reach anyway (and we can increase it if needed). So as you can see, what limits direct-path is the number of destination endpoints and not the number of flows. So we have no issue with your second point.

For the first point, Direct-path is also in effect, except that the packet skips the bouncer hop and is sent to the divider (not the end host). So for cross-subnet with direct-path, the packet will make 2-hops, instead of 4. Although we can make a host-to-host direct path as well in this case, we choose not to do it for the following functional reasons:

1. It's hard to know if the packet is designated for a subnet in the same VPC or in a different VPC. In the later-case, we will need to send the packet to the divider.
2. All the Network Access Control List will be implemented at the divider and has to be evaluated for each packet (not for each flow).

So for these functional reasons, we decided that direct-path for cross-subnet packets will still go through the divider (but skips the bouncers). Hope this answers your questions.

[Eric-Yuan]

Thanks for the detailed answers. But I still have some doubt about the second point, that the extra hop might cause enormous packets in dividers, and those extra bandwidth cost might make Mizar a disadvantage in commercial considerations. So If we could also provide a not perfect but more competitive in commercial considerations design as a alternative option?

[Eric-Yuan]

sorry, that is the first point

[zasherif]

I understand your point. The initial thought of this would have been addressed by horizontal scaling of dividers (maybe also pricing models). That's said, do you have data for the ratio of cross-network traffic to total traffic? Also, do you have an estimate of the size and frequency of updates of network ACLs in a prod? If these are not enormous as well and not updated frequently, we can reconsider evaluating them at the end-host and not at the divider. In that case, it is relatively straightforward for us to change direct-path to be always host-to-host even for cross-network traffic. LMK if you can help and provide some numbers.

[zasherif]

In all cases, I created this issue to make the divider behavior configurable for direct-path: https://github.com/futurewei-cloud/mizar/issues/192 . Hope this will address your first point.

[zasherif]

@Eric-Yuan let me know also if you like to take a stab and contribute that change. Will be happy to merge your contribution.

[Eric-Yuan]

Thanks, I will try to get some numbers to feedback.

[deepak-vij]

Shouldn't "host-to-host" (ACL enforced at the host level) versus one extra "divider" (ACL enforced at the higher divider level) hop packet communication options across subnet/vpc scenario be configurable depending on the needs of the business.