# Event-Driven Testing For Edge Applications

Fotis Nikolaidis  Institute of Computer Science,
FORTH (ICS)
Heraklion, Greece
<EMAIL_ADDRESS>Antony Chazapis  Institute of Computer Science,
FORTH (ICS)
Heraklion, Greece
<EMAIL_ADDRESS>Manolis Marazakis  Institute of Computer Science,
FORTH (ICS)
Heraklion, Greece
<EMAIL_ADDRESS>Angelos Bilas  Institute of Computer Science,
FORTH (ICS)
Heraklion, Greece
<EMAIL_ADDRESS>
###### Abstract

With the rise of the Internet of Things (IoT) and Edge computing, a
considerable amount of system services are moving from reliable Cloud data
centers to less reliable infrastructures closer to the end-users. However, the
constrained resources, unreliable communication, and varying operating
conditions of IoT pose significant complexities for software vendors in
testing their applications. Although several emulators exist for testing IoT
systems, numerous issues can be pointed out, such as lacking support for
logical dependencies and advanced fault injection capabilities, requiring
manual validation of the system’s behavior, or focusing on a specific platform
and language. To address these limitations, we propose Frisbee: a framework
for the automated testing of IoT applications. Frisbee accelerates the testing
process by simplifying the spin-up of distributed virtual testbeds over
Kubernetes and the description of ‘what-if’ scenarios that integrate complex
sequences of workloads and faultloads.

###### Index Terms:

Testbed automation and orchestration, benchmarking fault tolerance mechanisms,
scalability and efficiency of test runs and testbeds

##  I Introduction

The Internet-of-Things (IoT) poses one of the most significant and widespread
systems, where errors directly impact people’s lives. Testing and validating
is how one deals with errors; but testing and validating a planetary-scale,
heterogeneous, and ever-growing ecosystem has its own challenges. Although
individual IoT devices have limited functionalities and are easy to test, the
testing can become remarkably complex when we consider thousands of devices
deployed in dynamic topologies, unreliable connectivity, and device or
protocol heterogeneity.

For this reason, a considerable amount of work has been done on virtual
testbeds that replicate the physical properties of an IoT infrastructure.
Virtual testbeds like Fogify [1] and IOTier [2] can transform a cluster of lab
machines into a Virtual Environment that supports complex topologies comprised
of heterogeneous resources and versatile network capabilities with multiple
QoS criteria. However, the testbeds only provide the testing infrastructure.
Testers will still have to think long and hard about how to evaluate a complex
distributed system such as an IoT deployment and how they want to structure
their test operations.

The first challenge for testers is to bring the System Under Testing (SUT)
into an initial working state. This can be a particularly involved process
since IoT consists of multiple dependent services that must be boot in a
specific order. Unfortunately, almost all developed IoT emulators are time-
driven, meaning that all actions are scheduled in fixed intervals without
accounting for the system’s state. As a result, even slight changes in the
initial conditions across executions (e.g., CPU load) can lead to premature or
delayed actions that hinder the credibility of the test case.

The second challenge is to assess how the system reacts to different workload
and faultload configurations. Despite the abundance of workload-generating
benchmarks and fault-injecting Chaos tools, the lack of a unified tool has led
to severe fragmentation in testing methodology and poor comparability of
results. Prior studies approached the subject by submitting a running system
into randomized, negative behavior, like shutting down nodes, introducing CPU
and network stressors, or injecting faults. The goal is to uncover shallow
(independent) bugs [3] early in the development cycle [4, 5]. However, random
strategies are unlikely to reveal “deep” failures which manifest under
specific operating conditions [6], e.g., quorum bugs that appear when
connectivity is broken during the synchronization of a replica-set [7]. Not
surprisingly, prior studies have reported fault injection campaigns with no
faults activated in as many as 40% of the experiments [8, 9]. This untested
code, often the error recovery code, will tend to be an error-prone part of a
system [10].

Finally, neither existing Chaos tools nor Virtual Testbeds provide the means
for assessing the impact of a fault. Consequently, the tester has to design
and maintain monitoring mechanisms to ensure that the test case completes
without failures, without correctness issues [11], and without SLO violations
[12]. We argue that these shortcomings tend to make the end-to-end testing
come late in the development cycle; when bugs are revealed, reworked, and the
additional retesting cost is high and impacts the product release [13, 14].

This paper presents Frisbee, the first unified platform to support end-to-end
testing over Kubernetes. Unlike all prior tools, Frisbee delivers a fully
automated testing environment that can spin up multiple containers on-demand,
awaiting containers to start up and load data (plus dependent containers),
then manipulating containers (e.g., via fault injection), and validating that
the system behaves as expected. To achieve that, Frisbee integrated a
combination of Cloud platforms, event-driven workflows, Chaos toolkits, and a
well-integrated distributed monitoring stack that provides insights and
alerting about the system’s state.

Our contributions are:

  * •

A DSL that combines complex workloads with faultloads.

  * •

A methodology for execution-driven fault injection that allows injecting a
controlled and predetermined faultload distribution as the system executes at
runtime.

  * •

A design for repurposing existing monitoring tools for the automated assertion
of a distributed system’s behavior and side effects.

  * •

A set of patterns for Load testing, SSTable Corruption, and Goroutine Leaking,
for a Cloud database that supports IoT applications.

##  II The Frisbee Framework

###  II-A Features

With Frisbee, developers of IoT applications, who seek to explore application
performance and reliability under various operational conditions, can overcome
the challenges mentioned above by being provided with the following features:

Extensibile and Portable Testbed We carefully designed Frisbee to be easily
extensible, portable, and practical. We implemented the Frisbee core features
to operate in Kubernetes to decouple our framework from any system-specific
constraints and provide similar environments for dev, test, and production.
Doing so, Frisbee scenarios are reproducible across local workstations (e.g.,
minikube, microk8s), bare-metal cluster setups (e.g., k8s), as well as in the
Cloud deployments (e.g., EKS).

Event-Driven Initialization, Workload and Faultload For controllability and
precision of the executed actions, Frisbee provides direct access to the
runtime environment, allowing users to build execution-driven scenarios. This
way, testers can i) spin up the dependency stack of the SUT in a deterministic
manner; ii) build complex workloads with dynamically changing request
patterns; and iii) surgically inject faults into specific locations without
introducing spurious faults that may compromise the validity of the results.

Failure-Aware Semantics Another advantage of managing the SUT and the failure
injection from within the same workflow is the ability to distinguish an
unexpected service failure (i.e., due to a bug in the application’s code) from
an expected service failure (i.e., part of a Chaos experiment). That is a
highly-required feature in resiliency testing [15] since in the first case,
the test should abort immediately, whereas in the second case, the fault does
not constitute a culpable failure, and the test should continue.

Contextualized Visualizations: Particular emphasis is given to supplying
additional interpretation and contextual data that help testers visually
correlate the observed behavior with a root event. For instance, an annotation
marking a network fault’s injection could help explain an otherwise enigmatic
drop in the system’s throughput. To achieve that, when Frisbee performs an
action (e.g., create a service, inject a fault), it interacts with Grafana to
annotate the action’s beginning and ending.

Hierarchical Assertions Since testing workflows are defined hierarchically
(e.g., clusters managing hundreds of services), it is rather natural to
consider the partitioning of large verification problems into a set of
properties associated locally with the entities of the workflow hierarchy
[16]. Instead of large and complex assertions, Frisbee promotes the
decomposition of complex properties into simpler assertions, provable at the
action level.

###  II-B System Overview

Figure 1: Frisbee architecture. Given a template describing the system under
test and a workflow describing the experiment, Frisbee interfaces with
Kubernetes to run the experiment. Notice the loop among controllers, telemetry
stack, and kubernetes API.

Figure 1 depicts a high-level overview of the Frisbee architecture. Built over
the Operator pattern of Kubernetes [17], Frisbee consists of Custom Resource
Definitions (CRDs) and a collection of controllers. A CRD defines a new,
unique object Kind in the Kubernetes API, listing out all of the
configurations for describing the desired state of that object. A controller
is a software loop that watches the Kubernetes API for changes and, if
necessary, takes actions to reconcile the expressed desired state and the
current state of an object.

The experiment starts with specifying the testing resources in a YAML file.
The most important are the templates that describe the System Under Testing
(SUT) and the action workflow that drives the testing process. The workflow is
a directed acyclic graph (DAG) whose nodes represent jobs that change the
execution environment and can be either constructive (e.g., create a new
service) or destructive (e.g., kill a service, inject a network fault). The
edges represent a bidirectional parent-child relationship between jobs. Every
parent is responsible for overseeing the creation and the management of its
constituent jobs and updating its status accordingly. This hierarchy
facilitates decentralized testing (fewer jobs to be managed by the central
workflow controller) and provides context-based execution for decoupling the
outcome of the test case from individually failing services.

Users do not directly interact with the Frisbee Controller Manager. Instead,
when the scenario is ready for deployment, the user submits it to the
Kubernetes API via the standard kubectl tool. In turn, the Kubernetes API
submits the scenario to the registered Frisbee controller, which checks for
malformed dependencies and errors in expressions (e.g., assertions,
conditional branches) before the actual deployment. This validation enables us
to avoid loops and guarantee that a test case should not continue running
forever, preventing other test cases from execution. Subsequently, Kubernetes
triggers a reconciliation cycle to the workflow controller. During this cycle,
the controller traverses the workflow graph and executes the listed jobs. In
general, jobs are executed immediately unless the tester has defined
scheduling constraints or logical dependencies to other jobs. In this case,
the execution is postponed until one of the events of Table I is fired.

Upon a fired event, the controller starts a new reconciliation cycle during
which it interacts with the Kubernetes API (e.g., create, update or delete
objects) or performs some action on other systems, e.g., disseminate policies
to Frisbee agents at the execution layer. Frisbee uses sidecar agents to
interact with application containers [18, 19], in a non-intrusive manner.
Agents exist for CPU or network throttling, monitoring system resources (CPU,
memory, network, IOPS), monitoring application metrics (e.g., quorum state,
replication role), and injecting faults (even network partition are rules set
by a network agent to the routing table of the pod).

Event |  Description
---|---
Time-driven |  Fired after an elapsed time measured by the controller.
State-driven |  Fired by the Kubernetes API when managed objects have state changes, errors, or other messages that should be broadcast to the system.
Metrics-driven |  Fired by the telemetry stack when the outcome of statistical analysis on the collected metrics matches a given rule.
Tag-events |  Fired when one controller passes contextual information to another controller.
TABLE I: Events used to drive assertions, conditional loops, and other places
involving execution-driven knowledge.

##  III Implementation Details

###  III-A Scenario Modeling

A Frisbee scenario describes a set of dependent actions that collectively
describe the testing process. The scenario defines three important properties:
1. a list of actions that drive the testing process,  2. the preconditions of
the runtime before each action, and  3. the desired state of the runtime after
each action.

Actions covers a full range of operations required to test a distributed
system, and consists of five comprehensive and fine-grained abstractions:
services, clusters, faults, calls, and checkpoints. Descriptions are in Table
II. Under the hood, actions invoke templates that provide solid definitions of
the SUT. This strategy allows us to create a library of frequently-used
specifications and use them to generate objects on-demand throughout the
experiment. When called without parameters, templates generate services
initialized with reasonable defaults. With parameters, templates generate the
customized configuration by replacing the placeholders (denoted as …) with the
given input. Due to the limited space, we only provide the definition of a
scenario 2, not the underlying templates.

Action |  Description
---|---
Service |  Standard representation of a containerized application.
Cluster |  Abstraction for managing multiple services in a shared execution context.
Fault |  Condition that disturbs a running service, network, or storage.
Call |  Command executed by the controller to a running service.
Checkpoint |  Store the status and the metrics of the SUT at the given time.
TABLE II: Using just 5 basic primitives, Frisbee covers a full range of
operations required to test a distributed system.

⬇

spec:

# Step 0. Provision 4 individual servers

- action: Cluster

name: masters

cluster:

templateRef: cockroach.cluster.master

instances: 4

# Step 1. Create a cockroach cluster

- action: Call

name: boot

depends: { running: [ masters ] }

call:

callable: boot

services: [ .cluster.masters.all ]

# Step 2. Import TPC-C data from node-0

- action: Call

name: import-workload

depends: { success: [ boot ] }

call:

callable: import-tpcc

services: [ masters-0 ]

# Step 3. Wait for 3x replication

- action: Call

name: wait-for-3x-replication

depends: { success: [ import-workload ] }

call:

callable: wait-for-3x-replication

services: [ .cluster.masters.all ]

# Step 4. Run TPC-C workload from the node 3\.

- action: Call

name: run-workload

depends: { success: [ wait-for-3x-replication ] }

call:

callable: run-workload

services: [ masters-3 ]

# Step5. Partition node 1 from the rest of the nodes;

- action: Chaos

name: partition0

depends: { success: [ wait-for-3x-replication ]}

chaos:

templateRef: system.chaos.network.partition.partial

inputs:

- { source: masters-0,

direction: ”to”, duration: 10m,

dst: ”masters-1, masters-2, masters-3” }

Scenario demonstrating action with logical dependencies (depends),
parameterization (inputs), addressing macros (.cluster), and injection of
templates faults.

###  III-B Extensibility and Integration with Chaos Controllers

Every action in Frisbee is represented by a different CRD and is managed by a
separate controller, e.g, the cluster action will handled by the Cluster
controller. Practically, this architecture builds a tree of domain-specific
controllers with a top-level controller (the scenario) that dispatch requests
based on the type of action. Controllers interact by submitting and receiving
requests recorded in the Kubernetes API. In the previous example, the Scenario
controller will create a Cluster resource to the Kubernetes API, that will be
subsequently captured by the Cluster controller. After handling the request,
the Cluster controller will modify the Cluster resource with the updated
status, and the Kubernetes API will notify the Scenario controller about the
change.

###  III-C Manage Dependencies Between Actions

To manage the logical dependencies between actions, the scenario controller
should inspect the status of the various actions (stored in the Kubernetes
API) and, once it comes to the desired state, trigger the following action.
This, however, requires the Scenario controller to know how to parse the
various statuses and understand their semantics. One solution is to let the
user specify parsing rules for each action and explicitly model the reaction
to every possible outcome. Instead of this laborious task, we have set a
common phase-field so that all objects managed by Frisbee can consistently
communicate where they are in their lifecycle. The values and their meaning
are tightly guarded, as shown in Table III.

Phase |  Description
---|---
Uninitialized |  the request has been accepted by the Kubernetes API, but it is not yet dispatched to the Frisbee controller.
Pending |  the request has been accepted by a Frisbee controller, but at least one of the constituent jobs has not been created.
Running |  all constituent jobs of the request have been created, and at least one job has not been completed yet.
Success |  all the constituent jobs of a request have been successfully completed.
Failed |  at least one job of the request has terminated in a failure.
TABLE III: Lifecycle Semantics. Logical Dependencies are built upon them.

###  III-D Expected versus Unexpected Failures

Frisbee features a holistic approach to failure detection, propagation, and
recovery [20], which provide testers the ability to distinguish between
expected and unexpected failure, as shown in Figure 3. The basis of our
mechanism is that almost all fault-injections in Kubernetes happen at a Pod
level. Whenever the workflow controller encounters a Chaos action, it
traverses the ownership semantics for finding the service responsible for the
affected pod and places a metadata.Chaos tag on it. This tag describes the
type of impending fault (e.g., partition, kill). It then applies the action.
If the pod crashes, the failure is propagated to the service via the status
updating mechanisms, making the service fail as well. When this happens, the
service owner (i.e., cluster) can conclude whether the failure is expected or
not by inspecting the service’s metadata for the presence of a chaos tag. If
there is no tag, the failure is unexpected, and the cluster fails immediately
to cut losses and quickly try something else. If there is a tag, the failure
is expected, and the behavior is tunable according to the clusters’ semantics,
e.g., the number of tolerated failures.

Figure 3: Information propagation for distinguishing unexpected failures
caused by application bugs, from expected failures caused by fault-injection
jobs. Chaos controller marks the service owning the targeted pod with an
indicative tag before it applies the chaos action.

###  III-E Extract State and Performance Metrics

Expressions in Frisbee can be state-driven or metrics-driven.

  * •

State Expressions are used to describe dependencies on the lifecycle of a
Kubernetes object (i.e when a service has failed). They consume state events
fired by the Kubernetes API. For simplicity, we provide a set of aggregation
functions that are callable from within the expressions, e.g.,
‘.state.failed() ¿ 4‘. Expressions can also be combined into complex
assertions via logical/arithmetic/string comparators.

  * •

Metrics Expressions are used to describe dependencies on the performance of a
running service (i.e when percentile latency exceeds a given limit). They
involve an initial step for setting an alert to Grafana and then checking if
the alert is fired. For interoperability, we have adopted the Grafana syntax
for writing alerts. For example, ”MAX() QUERY(metric, 1m, now) IS
ABOVE(70000)” roughly translates as ‘raise an alert if the max value of the
given metric for the period between not and 1 minute ago has been above
70000‘.

The expressions are well-integrated into the Frisbee language and are reusable
across assertion, conditional loops, and other places involving execution-
driven knowledge. Additionally, the extracted output of the expressions can be
stored using the Checkpoint action. As demonstrated in the Evaluation Section,
the Checkpoint allows us to take snapshots and use this information in
assertions to compare performance metrics before and after an action (i.e.,
network partition).

###  III-F Scoped Assertions

Every resource managed by Frisbee (e.g., services, faults, clusters, cascade)
has its own assertions. The main benefit is that we can isolate failed
services while allowing the workflow components to synchronize their knowledge
and correlate individual failures to top-level events [21, 22]. For state-
based expressions, the assertions only consider jobs in the local scope –
those created by the entity. This way, we prevent cross-references on jobs
belonging to a different resource, thus saving the user from never-ending
loops. Nonetheless, we cannot wholly exclude cross-references, given that
metrics-driven expressions have access to the common telemetry stack.
Therefore, we prevent cross-references to a job but not to a job’s performance
metrics. Regardless of this peculiar case, we still permit top-level
assertions to use available assertions at lower hierarchy levels.

##  IV Evaluation

We evaluate Frisbee using the CockroachDB. The decision was based on two
factors. Firstly, CockroachDB is getting traction from IoT community as it
supports numerous required features, such as stability, scalability, SQL-
compliance, ACID Transactions, Kubernetes compability, and data locality [23].
Secondly, CockroachDB have open-sourced their own tool (roachtest) for
performing large-scale (multi-machine) automated tests, and have a large
collection of testing scenarios that we replicate in Frisbee.

For the evaluation, we used a Kubernetes cluster of 4 server-grade nodes. Each
node has 24-cores (2 Intel Xeon E5-2630v3 CPUs), 128 GB of DDR3 ECC main
memory, and 250 GB of locally attached NVMe storage. The machines are
connected via 1Gbps links to the top-of-rack switch. We configured CockroachDB
and YCSB benchmarks using the default settings. For the monitoring we used the
bitnami containers Telegraf, Prometheus, and Grafana. For failure injection,
we use Chaos-Mesh [24].

Load Testing To assess the precision of Frisbee’s event-driven strategy, we
performed load testing experiments using a sequence of YCSB workloads.
Roughly, the scenario performs the following steps,  1. Create a cockroach
cluster;  2. Preload the server with keys;  3. Run YCSB workload A;  4. Run
YCSB workload B;  5. Run YCSB workload C;  6. Run YCSB workload F;  7. Run
YCSB workload D;  8. Reload the database;  9. Run YCSB workload E.

In each experiment, we use a different invocation strategy (Kubernetes
Vanilla, Time-Driven, State-Driven), and collect statistics on system
utilization (CPU cycles) and application-specific metrics (Go routines)
consumed by the database servers. As shown in Figure 4, the vanilla Kubernetes
policy is to start all jobs in parallel, which makes the experiment extremely
flaky. This is because Kubernetes by default always expects the ‘final’, or
the desired, state of a resource, thus does not provide primitives for logical
dependencies. With the sleeping instrumentation, we see that there are no
scheduling guarantees. If the sleeping time is small, subsequent stages of the
workflow will overlap, leading to erroneous results. If the sleeping time is
large, there is a huge portion of idle time, that is translated to long-
running experiments with increased time and energy costs. In contrast, state-
driven execution appears to respect the ordering of the jobs, irrespectively
of the number of ingested keys.

(a) Kubernetes Scheduling, 500 keys

(b) Time-Driven Scheduling, 500 Keys

(c) State-Driven Scheduling, 500 Keys

(d) State-Driven Scheduling, 1M keys

Figure 4: Scheduling Policies for the standard sequence of YCSB workloads
(A,B,C,F,D,E)

SSTable Corruption This scenario is adopted from the roachtest suite [25] and
is designed to test if the storage layer (pebble) can detect corrupted SST
files and panic, i.e., fail fast. Roughly, it performs the following steps,
1. provision 3-node cluster  2. import TPC-C data from the workload node (node
1)  3. find 6 random SST files on each node (abort if node has fewer)  4.
corrupt each of the 6 SST files on each node  5. start each node, verify each
node panics  6. if nodes don’t panic, run TPC-C workload for up-to 10 mins
(node1)  7. verify cluster panic  8. fail the test if DeadlineExceeded or
Cancelled (workload finished but no panic occurred)

As can be seen in Figure 5, Frisbee can successfully detect the panicked
service and aborts the experiment. It worth mentioning that since this
experiment is implemented using the Call primitive. In contrast to Services
which are intended to be ‘long-running’ and are marked using point
annotations, Calls are intended to be ‘short-living’, and therefore are
annotated as regions, marking the beginning and the ending of a Call.

Figure 5: SSTable corruption, with assertions

Goroutine Leak This scenario is adopted from the roachtest suite [26] and is
designed to test for leaking goroutines after recovering from a network
partition. Roughly, it performs the following steps:  1. provision 4-node
cluster  2. import TPC-C data (node 1)  3. wait for 3x replication  4. run
TPC-C workload from the workload node (node 4)  5. record maximum number of
goroutines observed thus far, i.e., maxSeen  6. partition node 1 from the rest
of the nodes; node 1 can reach other nodes, but no other nodes can reach node
1  7. continue running with the simulated network partition for 1 hour,
regularly updating maxSeen  8. remove network partition  9. verify max number
of goroutines has not spiked wrt maxSeen

As can be seen in Figure 6, Frisbee can successfully inject and repair a
network partition fault. However, the number of goroutines after the partition
have not spiked, and Frisbee correctly continues the execution of the test.

Figure 6: Network Partition

##  V Related Work

Frisbee adheres to the two rules of end-to-end testing: help developers focus
on the test case rather than test the testing mechanisms, and create similar
environments for dev, test, and production. We compare the related work
concerning these two rules.

Test source code: Frameworks like Ginkgo for Go, Robot for python, or Serenity
for Java, provide a rich and expressive DSL (Domain-specific Language) for
writing test scenarios. In return, the framework engine implements the
scenario using thin threads, each representing a single service [27, 28].
However, this approach is impractical for systems whose components are written
in different languages.

Test processes in physical infrastructure: Despite its simplicity, this
approach comes with many known deficits, drifting library versions, shared
namespaces on a host (e.g., two services cannot listen on the same port),
library inconsistencies, and limited intervention on a shared infrastructure.
Chef and Puppet provide declarative to automate the deployment and
configuration of testing objects (e.g., servers, benchmarks). However, since
these tools are designed for deployment and configuration, they expect the
‘final’ state of the system. In contrast, testing generally involves multiple
‘intermediate’ steps with logical dependencies between them.

Test containers in Docker With the popularisation of Docker, the testing
community turned into replacing virtual machines with containers. In the early
stages, containers were managed by scripts. This manual approach was
cumbersome and mixed the test case with the testing mechanism. Later on, the
Docker-native approach followed by BenchPilot [29], Fogify [1], and IOTier
[2], was to use the Docker-Compose language for running multi-container tests.
However, besides lacking assertions in the language, Docker-compose works for
single-node deployments.

Test containers natively in Kubernetes KUTTL [30] and Iter8 [31] are
Kubernetes-native testing tools, but their goals is different from ours. KUTTL
is a toolkit for testing a Kubernetes controller, not a Kubernetes controller
for testing other systems. Iter8 aims at automating the progressive rollout of
microservices. To do so, they create two experiments. One Iter8 experiment for
deploying microservices instrumented with telemetry agents, and one chaos
experiment (via Litmus) for periodically killing the deployed microservices.
However, since there is no coordination between the two experiments, the chaos
experiment is execution-agnostic, and the final result is hardly reproducible.

##  VI Conclusion

Because our systems and system designs have evolved in such an unprecedented
way, we must also evolve our testing methods to better understand how our
systems perform under normal and adverse operating conditions. We believe the
answer lies in building a new generation testing tools that can support truly
precise, controllable, observable, and language-agnostic experiments. With
Frisbee, our ultimate goal is to foster the development of a common Cloud-
Native Testing Framework [32] for systems researchers and practitioners, in
order to support dependable, reproducible, and comparable experiments in Chaos
campaigns. The Frisbee and the experiments are made available open-source at
https://frisbee.dev.

## Acknowledgement

This project has received funding from the European Union’s Horizon 2020
research and innovation programme under the Marie Skłodowska-Curie, grant
agreement No. 894204 (Ether, H2020-MSCA-IF-2019).

## References

  * [1] M. Symeonides, Z. Georgiou, D. Trihinas, G. Pallis, and M. D. Dikaiakos, “Fogify: A fog computing emulation framework,” in _2020 IEEE/ACM Symposium on Edge Computing (SEC)_. IEEE, 2020, pp. 42–54.
  * [2] F. Nikolaidis, M. Marazakis, and A. Bilas, “Iotier: A virtual testbed to evaluate systems for iot environments,” in _2021 IEEE/ACM 21st International Symposium on Cluster, Cloud and Internet Computing (CCGrid)_. IEEE, 2021, pp. 676–683.
  * [3] W.-L. Kao and R. K. Iyer, “Define: A distributed fault injection and monitoring environment,” in _Proceedings of IEEE Workshop on Fault-Tolerant Parallel and Distributed Systems_. IEEE, 1996, pp. 252–259.
  * [4] A. Abedi and T. Brecht, “Conducting repeatable experiments in highly variable cloud computing environments,” in _Proceedings of the 8th ACM/SPEC on International Conference on Performance Engineering_ , 2017, pp. 287–292.
  * [5] P. Leitner and J. Cito, “Patterns in the chaos—a study of performance variation and predictability in public iaas clouds,” _ACM Transactions on Internet Technology (TOIT)_ , vol. 16, no. 3, pp. 1–23, 2016.
  * [6] C. Giuffrida, A. Kuijsten, and A. S. Tanenbaum, “Edfi: A dependable fault injection tool for dependability benchmarking experiments,” in _2013 IEEE 19th Pacific Rim International Symposium on Dependable Computing_. IEEE, 2013, pp. 31–40.
  * [7] CockroachDB. (2022, Aug.) Recovery problems after network partition. [Online]. Available: https://jira.mongodb.org/browse/SERVER-23003
  * [8] W. T. Ng and P. M. Chen, “The design and verification of the rio file cache,” _IEEE Transactions on Computers_ , vol. 50, no. 4, pp. 322–337, 2001.
  * [9] A. Simão and A. Petrenko, “Fault coverage-driven incremental test generation,” _The Computer Journal_ , vol. 53, no. 9, pp. 1508–1522, 2010\.
  * [10] F. Nikolaidis, A. Chazapis, M. Marazakis, and A. Bilas, “Frisbee: A suite for benchmarking systems recovery,” in _Proceedings of the 1st Workshop on High Availability and Observability of Cloud Systems_ , ser. HAOC ’21. New York, NY, USA: Association for Computing Machinery, 2021, p. 18–24. [Online]. Available: https://doi.org/10.1145/3447851.3458738
  * [11] Jepsen. (2020, Aug.) A framework for distributed systems verification, with fault injection. [Online]. Available: https://github.com/jepsen-io/jepsen
  * [12] G. Candea, S. Bucur, and C. Zamfir, “Automated software testing as a service,” in _Proceedings of the 1st ACM Symposium on Cloud Computing_ , ser. SoCC ’10. New York, NY, USA: Association for Computing Machinery, 2010, p. 155–160. [Online]. Available: https://doi.org/10.1145/1807128.1807153
  * [13] M. Doležel, “Defining testops: Collaborative behaviors and technology-driven workflows seen as enablers of effective software testing in devops,” in _Agile Processes in Software Engineering and Extreme Programming – Workshops_ , M. Paasivaara and P. Kruchten, Eds. Cham: Springer International Publishing, 2020, pp. 253–261.
  * [14] S. Miller and D. Firesmith, “Four types of shift left testing,” CARNEGIE-MELLON UNIV PITTSBURGH PA, Tech. Rep., 2021.
  * [15] R. Tolosana-Calasanz, J. A. Banares, O. F. Rana, P. Álvarez, J. Ezpeleta, and A. Hoheisel, “Adaptive exception handling for scientific workflows,” _Concurrency and computation: Practice and experience_ , vol. 22, no. 5, pp. 617–642, 2010.
  * [16] A. Kasuya and T. Tesfaye, “Verification methodologies in a tlm-to-rtl design flow,” in _2007 44th ACM/IEEE Design Automation Conference_. IEEE, 2007, pp. 199–204.
  * [17] Kubernetes. (2021, Aug.) Operator best practices. [Online]. Available: https://sdk.operatorframework.io/docs/best-practices/best-practices/
  * [18] B. Burns, _Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services_. ” O’Reilly Media, Inc.”, 2018.
  * [19] B. Burns and D. Oppenheimer, “Design patterns for container-based distributed systems,” in _8th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 16)_. Denver, CO: USENIX Association, Jun. 2016. [Online]. Available: https://www.usenix.org/conference/hotcloud16/workshop-program/presentation/burns
  * [20] S. Herbein, D. Domyancic, P. Minner, I. Laguna, R. da Silva, and D. Ahn, “Mcem: Multi-level cooperative exception model,” Lawrence Livermore National Lab.(LLNL), Livermore, CA (United States), Tech. Rep., 2019.
  * [21] R. Gupta, P. Beckman, B.-H. Park, E. Lusk, P. Hargrove, A. Geist, D. Panda, A. Lumsdaine, and J. Dongarra, “Cifts: A coordinated infrastructure for fault-tolerant systems,” in _2009 International Conference on Parallel Processing_. IEEE, 2009, pp. 237–245.
  * [22] S. Di, R. Gupta, M. Snir, E. Pershey, and F. Cappello, “Logaider: A tool for mining potential correlations of hpc log events,” in _2017 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID)_. IEEE, 2017, pp. 442–451.
  * [23] CockroachDB. (2022, Mar.) Movatic deploys cockroachdb in kubernetes for iot workloads. [Online]. Available: https://www.cockroachlabs.com/customers/movatic/
  * [24] PingCAP. (2020) A chaos engineering platform for kubernetes. [Online]. Available: https://github.com/chaos-mesh/chaos-mesh
  * [25] CockroachDB. (2022, Mar.) Sstable corruption. [Online]. Available: https://github.com/cockroachdb/…/roachtest/tests/sstable_corruption.go
  * [26] ——. (2022, Mar.) Sstable corruption. [Online]. Available: https://github.com/cockroachdb/…/roachtest/tests/network.go
  * [27] X. Bai, W.-T. Tsai, R. Paul, T. Shen, and B. Li, “Distributed end-to-end testing management,” in _Proceedings Fifth IEEE International Enterprise Distributed Object Computing Conference_. IEEE, 2001, pp. 140–151.
  * [28] W.-T. Tsai, X. Bai, R. Paul, W. Shao, and V. Agarwal, “End-to-end integration testing design,” in _25th Annual International Computer Software and Applications Conference. COMPSAC 2001_. IEEE, 2001, pp. 166–171.
  * [29] J. Georgiou, M. Symeonides, M. Kasioulis, D. Trihinas, G. Pallis, and M. D. Dikaiakos, “Benchpilot: Repeatable & reproducible benchmarking for edge micro-dcs.”
  * [30] KUTTL. (2022, Mar.) What is kuttl? [Online]. Available: The KUbernetes Test TooL
  * [31] M. Toslali, S. Parthasarathy, F. Oliveira, H. Huang, and A. K. Coskun, _Iter8: Online Experimentation in the Cloud_. New York, NY, USA: Association for Computing Machinery, 2021, p. 289–304. [Online]. Available: https://doi.org/10.1145/3472883.3486984
  * [32] F. Nikolaidis, A. Chazapis, M. Marazakis, and A. Bilas, “Frisbee: automated testing of cloud-native applications in kubernetes,” _arXiv preprint arXiv:2109.10727_ , 2021.


Polarization-Induced Interaction as a Perturbation within Orbital Angular
Momentum (OAM) Modes of an Optical Fiber

Ramesh Bhandari

Laboratory for Physical Sciences, 8050 Greenmead Drive, College Park, Maryland
20740, USA

<EMAIL_ADDRESS>
###### Abstract

We investigate the role of polarization effects in orbital angular momentum
modes of an optical fiber. Specifically, we revisit the removal of the
degeneracy of the $HE$ and the $EH$ vector modes that exists within the weakly
guiding approximation (WGA); within WGA, these two vector modes coalesce into
a single spatial (scalar) orbital angular momentum (OAM) mode, defined by a
common topological charge and associated with left or right circular
polarization. While the polarization term of the vector wave equation acting
as a Hermitian perturbation operator accounts for the splitting of the $HE$
and the $EH$ vector modes, its extension to explain the accompanying field
correction, called the polarization-induced field, encounters hurdles; this
field is characterized by a topological charge differing by two in magnitude.
The problems are critically examined with a possible remedy and its
implications.

##  1 Introduction

In the weakly guiding approximation (WGA), the propagation of orbital angular
(OAM) modes within an optical fiber is often described by a scalar wave
equation, whose spatial solutions are independent of polarization[1, 2, 3, 4,
5]. However, when an externally prepared OAM mode is injected into a fiber, it
couples to the vector OAM modes, $HE_{l+1,m}$ or $EH_{l-1,m}$ ($l>1$)
according as the polarization of the input mode is left circular (photon spin
$S=h/(2\pi)$) or right circular ($S=-h/(2\pi)$). These vector OAM modes are
the solutions of the vector wave equation, expressed in the exponential basis
($e^{\pm il\theta}$) as opposed to the $\cos(l\theta),~{}\sin(\l\theta)$ basis
[1]; $h$ is the Planck’s constant; $l$ and $m$ are the topological charge and
the radial index, respectively, of the input OAM mode. The vector modes have a
slightly different propagation constant from each other as well as the scalar
propagation constant. The vector wave equation includes a polarization-
dependent term, or simply a _polarization_ term, which accounts for these
slight differences in propagation constants. The polarization term encompasses
two effects, one attributable to the spin-orbit (SO) interaction and a second,
independent of spin, to a _contact_ interaction in close analogy with _atomic
physics_ , where it appears as part of relativistic corrections [6, 7, 3].
While both the SO and the _contact_ interactions contribute to changes in
propagation constant, it is the spin-orbit interaction that causes the
breaking of the degeneracy between the $OAM$ modes of the same topological
charge but opposite spins (see, e.g.[3, 4, 8]); this degeneracy breaking gives
rise to the nondegenerate $HE_{l+1,m}$ and $EH_{l-1,m}$ modes.

In this paper, we critically examine the nature of the polarization effects as
a perturbation within the OAM modes of a fiber. In particular, we attempt to
understand the presence of the polarization-induced OAM component of the
vector modal field as a consequence of the polarization term treated as a
perturbation. It is well known that the transverse component of the vector
field within a fiber is composed of a modal field, which is the solution of
the scalar wave equation (vector wave equation without the polarization term),
plus a correction term to account for the absence of the polarization term.
The latter field is polarization-induced and is of order
$\Delta=(n_{1}^{2}-n_{2}^{2})/(2n_{1}^{2}))$, where $n_{1}$ and $n_{2}$ are
the refractive indices of the core and the cladding, respectively [1]. More
recently, it was shown that the transverse component of the vector OAM modal
field is in general decomposable into two OAM components, one of which is
characterized by a topological charge $l$ and the other by a topological
charge $l\pm 2$ [10, 11]. The second component is polarization induced and of
order $\Delta$ (in the _weakly guiding limit_ , where $n_{1}\rightarrow
n_{2}$, the parameter $\Delta\rightarrow 0$, and the polarization effects
discussed above disappear). The question then arises if the presence of this
polarization-induced component can be explained within the framework of
perturbation theory in the same way as the propagation constant splitting
between the vector modes and their scalar counterparts. A recent work [12]
motivates this connection, but the treatment is incomplete.

In Section 2, we review the well-known polarization- induced splitting between
the $HE_{l+1,m}$ and the $EH_{l-1,m}$ modes as a perturbative effect
originating in the polarization term of the vector wave equation.
Subsequently, in Section 3, we extend this concept to explain the existence of
the polarization-induced component, which is of topological charge, $l\pm 2$.
We find that this extension runs into problems of a physical nature, and
suggest a remedy with its ramifications. Section 4 is the summary.

##  2 Review of polarization effects as a perturbation

In what follows, we drop the radial index $m$ for convenience and clarity, and
denote the fields of the $HE_{l+1}$ and $EH_{l-1}$ vector modes by
$\vec{e}^{(l,1)}$ and $\vec{e}^{(l,-1)}$, respectively. The corresponding
transverse fields, $\vec{e}^{(l,\pm 1)}_{t}$, satisfy the vector wave equation
[1]

$(\nabla^{2}_{t}+k^{2}n^{2}(r))\vec{e}^{(l,\pm
1)}_{t}+\vec{\nabla_{t}}(\vec{e}^{(l,\pm
1)}_{t}.\vec{\nabla_{t}}ln(n^{2}))=\beta_{l\pm 1}^{2}\vec{e}^{(l,\pm 1)}_{t},$
(1)

where the third term on the left-hand-side is the _polarization_ term; the
transverse gradient $\vec{\nabla_{t}}$ in cylindrical polar coordinates
($r,\theta,z)$ is
$\vec{\nabla_{t}}=\partial/\partial{r}~{}\hat{r}+(1/r)\partial/\partial{\theta}~{}\hat{\theta}$
and the transverse Laplacian
$\nabla^{2}_{t}=\partial^{2}/\partial{r^{2}}+(1/r)\partial/\partial{r}+(1/r^{2})\partial^{2}/\partial{\theta^{2}}$.
The circular fiber is translationally invariant and further assumed to be
axisymmetric. The square of the refractive index is given by
$n^{2}(r)=n_{1}^{2}(1-2\Delta f(r))$, where $f(r)$ is the index profile,
$\Delta(=(n_{1}^{2}-n_{2}^{2})/(2n_{1}^{2}))<<1$ is the profile height
parameter, with $n_{1}$ the refractive index of the core and $n_{2}$ the
refractive index of the cladding as in a step-index fiber or a ring-core fiber
[13, 14]. As an example, $f(r)$ is a step-function for a step-index fiber,
being equal to zero for $r\leq a$ and equal to 1 for $r>a$, where parameter
$a$ is the fiber core radius; for the graded-index fibers, the index profile
$f(r)$ is parabolic, being $r^{2}$ in the region $r\leq a$ and 1 for $r>a$.
Parameter $\beta_{l,\pm 1}$ is the propagation constant of the field
propagating along the $z$ axis coincident with the fiber axis, and
$k=2\pi/\lambda$.

Because $\Delta<<1$, which is usually the case in commercial fibers, the
expression $ln(1-2\Delta f(r))\approx-2\Delta f(r)$, which then yields
$\vec{\nabla_{t}}ln(n^{2})=-2\Delta\partial f(r)/\partial r$. Thus, the
polarization term in Eq. 1 (in lowest order of $\Delta$) is proportional to
$\Delta$. In the limit $n_{1}\rightarrow n_{2}$, $\Delta\rightarrow 0$,
implying the polarization effects disappear. Eq. 1 then reduces to the scalar
wave equation:

$(\nabla^{2}_{t}+k^{2}n^{2}(r))\vec{\tilde{e}}^{(l,\pm
1)}_{t}=\tilde{\beta}_{l}^{2}\vec{\tilde{e}}^{(l,\pm 1)}_{t},$ (2)

where

$\vec{\tilde{e}}^{(l,\pm 1)}_{t}=O_{l}({r,\theta})\vec{\epsilon}_{\pm}.$ (3)

The polarization-independent spatial amplitude $O_{l}(r,\theta)$ is given by

$O_{l}(r,\theta)=(1/\sqrt{N}_{l})F_{l}(r)e^{il\theta}.$ (4)

$\vec{\epsilon}_{\pm}=1/\sqrt{2}(\hat{x}\pm i\hat{y})$ are the left/right
circularization corresponding respectively to (photon) spin values of $\pm 1$
in units of $h/(2\pi)$. Eq. 3 constitutes an orbital angular momentum (OAM)
modal field with total angular momentum $J(=L+S)$ equal to $(l\pm 1)h/(2\pi)$
per photon according as the polarization is left circular (spin $S=+1$) or
right circular (spin $S=-1$); $\tilde{\beta}_{l}$ is the corresponding scalar
propagation constant, and $N_{l}$ is a normalization constant (the reduction
of $\vec{e}^{(l,\pm 1)}_{t}$ to the expression, Eq. 3 is explicitly shown for
the step-index fiber in [10]).

Because the polarization term is of order $\Delta$ in Eq. 1, we expect the
polarization correction, $\delta\beta_{l,\pm 1}^{2}=\beta_{l,\pm
1}^{2}-\tilde{\beta}_{l}^{2}$ and the field correction, $\delta\vec{e}^{(l,\pm
1)}_{t}=\vec{e}^{(l,\pm 1)}_{t}-\vec{\tilde{e}}^{(l,\pm 1)}_{t}$ to be each of
order $\Delta$ in the first order of perturbation. Therefore, we replace
$\vec{e_{t}}^{(l,\pm 1)}$ in Eq. 1 with $\vec{\tilde{e}}_{t}^{(l,\pm 1)}$ (the
unperturbed solution) and substitute Eq. 2 in Eq. 1, we obtain $(\beta_{l,\pm
1}^{2}-\tilde{\beta}_{l}^{2})\vec{\tilde{e}}^{(l,\pm
1)}_{t}=\vec{\nabla_{t}}(\vec{\tilde{e}}^{(l,\pm
1)}_{t}.\vec{\nabla_{t}}ln(n^{2}))$. Taking the scalar product of the above
with $\vec{\tilde{e}}^{(l,\pm 1)}_{t}$, the polarization correction is

$\delta\beta_{l,\pm 1}^{2}=\beta_{l,\pm
1}^{2}-\tilde{\beta}_{l}^{2}=\int_{0}^{\infty}\int_{0}^{2\pi}\vec{\tilde{e}}^{*(l,\pm
1)}_{t}.\vec{\nabla_{t}}(\vec{\tilde{e}}^{(l,\pm
1)}_{t}.\vec{\nabla_{t}}ln(n^{2}))rdrd\theta,$ (5)

where $\vec{\tilde{e}}^{*(l,\pm 1)}_{t}$ is the complex conjugate of
$\vec{\tilde{e}}^{(l,\pm 1)}_{t}$. We now substitute Eqs. 3, 4, and the
expression $\vec{\epsilon}_{\pm}=1/\sqrt{2}(\hat{r}\pm i\hat{\theta})e^{\pm
i\theta}$ (in polar coordinates) into Eq. 5. Noting further that
$n^{2}=n^{2}(r)$ and fields vanish at the end points of the integral, $r=0$
and $r=\infty$, we find after performing integration by parts that

$\begin{split}\delta\beta^{2}_{l,\pm
1}&=\frac{\Delta}{N_{l}}\int_{0}^{\infty}\int_{0}^{2\pi}\frac{\partial
f(r)}{\partial
r}(F_{l}(r)\frac{dF_{l}(r)}{dr}\mp\frac{l}{r}F_{l}^{2}(r))rdrd\theta\\\
&=\frac{2\pi\Delta}{N_{l}}\int_{0}^{\infty}\frac{\partial f(r)}{\partial
r}(F_{l}(r)\frac{dF_{l}(r)}{dr}\mp\frac{l}{r}F_{l}^{2}(r))rdr,\end{split}$ (6)

from which $\delta\beta_{(l,\pm 1)}\approx\delta\beta^{2}_{(l,\pm
1)}/(2kn_{1})$ can be computed. $N_{l}=2\pi\int_{0}^{\infty}F^{2}_{l}(r)rdr$
is the normalization constant (see also [1] in the context of _Linearly-
Polarized (LP)_ modes). $\delta\beta^{2}_{(l,\pm 1)}$is of order $\Delta$, as
expected. The first term in Eq. 6 is identified with the contribution from the
_contact_ interaction (this designation arises from atomic physics, where the
reduction of the Dirac Hamiltonian for the electron in a central field in the
nonrelativisitc case yields, in addition to the spin-orbit interaction term,
an unknown nonclassical term, later identified with the $contact$ interaction
between an electron and the atomic nucleus [6, 7]). This contribution is
independent of the spin alignment with the OAM, but can be very large, as
demonstrated in the case of a step-index fiber [9]. The second term in Eq. 6
pertains to the spin-orbit interaction, which has a contribution equal in
magnitude but opposite in sign for the spin-orbit alignment $(l,1)$ and
nonalignment $(l,-1)$ cases. The same result is reproduced for the degenerate
states, characterized by $l$ and $S$ values of opposite signs, i.e.,
$\delta\beta^{2}_{-l,\mp 1}=\delta\beta^{2}_{l,\pm 1}$.

###  2.1 Polarization term as a perturbation operator

The result of Eq. 5 can be recast as a matrix element

$\delta\beta^{2}_{l,\pm 1}=<\vec{\tilde{e}}^{(l,\pm
1)}_{t}|V|\vec{\tilde{e}}^{(l,\pm 1)}_{t}>,$ (7)

where the operator $V$ represents the perturbative effects of the
_polarization_ term in Eq. 1. Subsequently, entire Eq. 1 in conjunction with
Eqs. 2 and 7 may be expressed as

$<\vec{\tilde{e}}^{(l,\pm 1)}_{t}|(H_{0}+V)|\vec{\tilde{e}}^{(l,\pm
1)}_{t}>=\tilde{\beta}_{l}^{2}+\delta\beta^{2}_{(l,\pm 1)},$ (8)

where $H_{0}=\nabla^{2}_{t}+k^{2}n^{2}(r)$; the same result holds for the
degenerate OAM-spin combinations: $(-l,-1)$ and $(-l,+1)$. The operator
$H_{0}+V$ is Hermitian (as expected) in the space defined by the four OAM
states with the OAM-spin combinations: $(l,1),(-l,1),(-l,-1),(-l,1)$. The off
diagonal elements of the $4~{}x~{}4$ matrix in this space are each zero; for
example,
$\delta\beta^{2}_{(-l,1)(l,1)}=<\vec{\tilde{e}}^{(-l,1)}_{t}|V|\vec{\tilde{e}}^{(l,1)}_{t}>$
given by
$\int_{0}^{\infty}\int_{0}^{2\pi}\vec{\tilde{e}}^{*(-l,1)}_{t}.\vec{\nabla_{t}}(\vec{\tilde{e}}^{(l,1)}_{t}.\vec{\nabla_{t}}ln(n^{2}))rdrd\theta$,
following Eq. 5, evaluates to zero, and so do others. The
$4~{}x~{}4~{}H_{0}+V$ matrix is therefore diagonal; each diagonal element
corresponds to a different value of the total angular momentum, $J=L+S$.

##  3 Extension of Perturbation Theory to Include the Polarization-Induced
Fields

We noted above that the polarization effects also induce a field correction,
$\delta\vec{e}^{(l,\pm 1)}_{t}$. This field correction is a state of
topological charge, $l\pm 2$, associated with polarization,
$\vec{\epsilon}_{\mp}$. This is easily seen from a generic form of the
transverse vector modal field of Eq. 1 : $\vec{e}^{(l,\pm 1)}_{t}=(e^{(l,\pm
1)}_{r}(r)\hat{r}+e^{(l,\pm 1)}_{\theta}(r)\hat{\theta})e^{i(l\pm 1)\theta}$,
which, upon substitution of $\hat{r}=\hat{x}\cos\theta+\hat{y}\sin\theta$ and
$\hat{\theta}=-\hat{x}\sin\theta+\hat{y}\cos\theta$, becomes

$\vec{e}^{(l,\pm
1)}_{t}=(1/{\sqrt{2})}\Big{[}\vec{\epsilon}_{\pm}e^{il\theta}\big{(}e^{(l+\pm
1)}_{r}(r)\mp ie^{(l,\pm 1)}_{\theta}(r)\big{)}+\vec{\epsilon}_{\mp}e^{i(l\pm
2)\theta}\big{(}e^{(l,\pm 1)}_{r}(r)\pm ie^{(l,\pm
1)}_{\theta}(r)\big{)}\Big{]}.$ (9)

The field has two components. The second component (of opposite polarization,
$\vec{\epsilon}_{\mp}$) is polarization induced and of order $\Delta$, as
discussed in Section 2. Therefore, in the limit $n_{1}\rightarrow n_{2}$, this
component goes to zero while the first component reduces to the traditional
scalar mode (see Eq. 3). A detailed analysis of Eq. 9 for a multilayered fiber
[10] reveals the novel result that the second term corresponds to a _modified_
scalar mode of topological charge $l\pm 2$, but for now we will work within
the framework of perturbation theory based on the traditional OAM modes of
Eqs. 3 and 4 (solutions of the scalar wave equation, Eq. 2). Function
$F_{l}(r)$ in Eq. 4 is the familiar Bessel function for a step-index fiber and
a combination of appropriate Bessel functions in the case of the ring-core
fiber [13, 14, bhandari4]. To extend the above perturbative model into the
space incorporating the states $(l\pm 2,\vec{\epsilon}_{\mp})$, we must
consider matrix elements such as
$<\vec{\tilde{e}}^{(l+2,-1)}_{t}|H_{0}+V|\vec{\tilde{e}}^{(l,+1)}_{t}>$ and
$<\vec{\tilde{e}}^{(l,1)}_{t}|H_{0}+V|\vec{\tilde{e}}^{(l+2,-1)}_{t}>$ for the
$J=L+S=l+1$ case, and similarly,
$<\vec{\tilde{e}}^{(l-2,1)}_{t}|H_{0}+V|\vec{\tilde{e}}^{(l,-1)}_{t}>$ and
$<\vec{\tilde{e}}^{(l,-1)}_{t}|H_{0}+V|\vec{\tilde{e}}^{(l-2,1)}_{t}>$ for the
$J=L+S=l-1$ case; integrations over $r$ and $\theta$ are performed as in Eq. 5
to evaluate them.

In the above expanded space and in particular its subspace spanned by the two
OAM states: $(l,1)$ and $(l+2,-1)$, each corresponding to total angular
momentum, $J=l+1$, we now consider the four matrix elements:
$<\vec{\tilde{e}}^{(l,1)}_{t}|H_{0}+V|\vec{\tilde{e}}^{(l,1)}_{t}>,~{}<\vec{\tilde{e}}^{(l+2,-1)}_{t}|H_{0}+V|\vec{\tilde{e}}^{(l+2,-1)}_{t}>,~{}<\vec{\tilde{e}}^{(l+2,-1)}_{t}|H_{0}+V|\vec{\tilde{e}}^{(l,1)}_{t}>$,
and $<\vec{\tilde{e}}^{(l,1)}_{t}|H_{0}+V|\vec{\tilde{e}}^{(l+2,-1)}_{t}>$ .
The matrix elements respectively equal
$\tilde{\beta}_{l}^{2}+\delta\beta^{2}_{l},~{}\tilde{\beta}_{l+2}^{2}+\delta\beta^{2}_{l+2},~{}\delta\beta^{2}_{l+2,l},~{}\delta\beta^{2}_{l,l+2}$
(in this abbreviated notation, where we suppress spin $S$, index $l$ is
equivalent to $(l,1)$, and index $l+2$ is equivalent to $(l+2,-1)$). The
operator $H=H_{0}+V$ is then represented by the $2~{}x~{}2$ matrix

$H=\begin{bmatrix}\tilde{\beta}_{l}^{2}+\delta\beta^{2}_{l}&\delta\beta^{2}_{l,l+2}\\\
\delta\beta^{2}_{l+2,l}&\tilde{\beta}_{l+2}^{2}+\delta\beta^{2}_{l+2}\end{bmatrix}.$
(10)

The above matrix is non-Hermitian because

$\begin{split}\delta\beta^{2}_{l+2,l}=<\vec{\tilde{e}}^{(l+2,-1)}_{t}|V|\vec{\tilde{e}}^{(l,1)}_{t}>&=\int_{0}^{\infty}\int_{0}^{2\pi}\vec{\tilde{e}}^{*(l+2,-1)}_{t}.\vec{\nabla_{t}}(\vec{\tilde{e}}^{(l,1)}_{t}.\vec{\nabla_{t}}ln(n^{2}))rdrd\theta\\\
&=\frac{2\pi\Delta}{\sqrt{N_{l}N_{l+2}}}\int_{0}^{\infty}\frac{\partial
f}{\partial
r}F_{l}\Big{(}\frac{dF_{l+2}}{dr}+\frac{l+2}{r}F_{l+2}\Big{)}rdr\end{split}$
(11)

is _not_ equal to

$\begin{split}\delta\beta^{2}_{l,l+2}=<\vec{\tilde{e}}^{(l,1)}_{t}|V|\vec{\tilde{e}}^{(l+2,-1)}_{t}>&=\int_{0}^{\infty}\int_{0}^{2\pi}\vec{\tilde{e}}^{*(l,1)}_{t}.\vec{\nabla_{t}}(\vec{\tilde{e}}^{(l+2,-1)}_{t}.\vec{\nabla_{t}}ln(n^{2}))rdrd\theta\\\
&=\frac{2\pi\Delta}{\sqrt{N_{l}N_{l+2}}}\int_{0}^{\infty}\frac{\partial
f}{\partial
r}F_{l+2}\Big{(}\frac{dF_{l}}{dr}-\frac{l}{r}F_{l}\Big{)}rdr~{};\end{split}$
(12)

the integrations here follow the same steps as in Eq. 5. Same conclusion is
reached for $J=l-1$ in a subspace spanned by the two OAM states; $(l,-1)$ and
$(l-2,1)$. This feature of the $H$ matrix is highly undesirable as it leads to
the violation of the orthogonality of the eigenstates. In the next section, we
explicitly demonstrate the nonorthogonality of the eigenstates of $H$ and
point out the related unphysical implications.

###  3.1 Consequences of the non-Hermitian matrix H

We examine the orthogonality of the eigenstates of matrix $H$. Its
diagonalization yields the eigenvalues:
$\lambda_{1}\approx\beta^{{}^{\prime}2}_{l}+\kappa^{2}/\beta^{\prime}_{D},~{}\lambda_{2}\approx\beta^{{}^{\prime}2}_{l+2}-\kappa^{2}/\beta^{\prime}_{D}$,
where
$\kappa^{2}=\delta\beta_{l,l+2}^{2}\delta\beta_{l+2,l}^{2},~{}\beta_{l}^{{}^{\prime}2}=\tilde{\beta}_{l}^{2}+\delta\beta_{l}^{2},~{}\beta_{l+2}^{{}^{\prime}2}=\tilde{\beta}_{l+2}^{2}+\delta\beta_{l+2}^{2};\beta^{\prime}_{D}=\tilde{\beta}_{l}^{{}^{\prime}2}-\tilde{\beta}_{l+2}^{{}^{\prime}2}\approx\tilde{\beta}_{l}^{2}-\tilde{\beta}_{l+2}^{2}$.
The eigenstate corresponding to eigenvalue $\lambda_{1}$ is a $2~{}x~{}1$
column vector:
$\psi_{1}=[1~{}~{}\delta\beta_{l,l+2}^{2}/\beta^{\prime}_{D}]^{T}$,
representing the field, $\vec{e}_{t}^{(l,+1)}$. In terms of the field
notation,

$\vec{e}_{t}^{(l,+1)}=O_{l}\epsilon_{+}+\Big{(}\frac{\delta\beta_{l,l+2}^{2}}{\tilde{\beta}^{2}_{l}-\tilde{\beta}^{2}_{l+2}}\Big{)}O_{l+2}\epsilon_{-}.$
(13)

Similarly, the eigenstate corresponding to the eigenvalue $\lambda_{2}$ is
found to be
$\psi_{2}=[-\delta\beta_{l+2,l}^{2}/\beta^{\prime}_{D}~{}~{}1]^{T}$, which
translates to

$\vec{e}_{t}^{(l+2,-1)}=O_{l+2}\epsilon_{-}-\Big{(}\frac{\delta\beta_{l+2,l}^{2}}{\tilde{\beta}^{2}_{l}-\tilde{\beta}^{2}_{l+2}}\Big{)}O_{l}\epsilon_{+}.$
(14)

The scalar product of the fields in Eqs. 13 and 14

$<\vec{e}_{t}^{(l+2,-1)}|\vec{e}^{(l,-1)}>=\frac{\delta\beta_{l,l+2}^{2}-\delta\beta_{l+2,l}^{2}}{\tilde{\beta}^{2}_{l}-\tilde{\beta}_{l+2}^{2}}\neq
0$ (15)

because $\delta\beta_{l+2,l}^{2}\neq\delta\beta_{l,l+2}^{2}$ as seen in
Section 3.

The above result violates the condition of orthogonality of the modes in a
fiber. Physically, this implies that an $(l,1)$ mode and an $(l+2,-1)$ mode
injected into an ideal, straight fiber (with no imperfections) will not travel
as independent states, but couple into each other. _This has the undesired and
misleading implication of crosstalk between two independent modes, $HE_{l+1}$
and $EH_{l+1}$ in an optical fiber_.

Similarly, in the $J=l-1$ case, composed of states, $O_{l}\epsilon_{-}$ and
$O_{l-2}\epsilon_{+}$, we obtain the results:

$\vec{e}_{t}^{(l,-1)}=O_{l}\epsilon_{-}+\Big{(}\frac{\delta\beta_{l,l-2}^{2}}{\tilde{\beta}^{2}_{l}-\tilde{\beta}^{2}_{l-2}}\Big{)}O_{l-2}\epsilon_{+}.$
(16)
$\vec{e}_{t}^{(l-2,1)}=O_{l-2}\epsilon_{+}-\Big{(}\frac{\delta\beta_{l-2,l}^{2}}{\tilde{\beta}^{2}_{l}-\tilde{\beta}^{2}_{l-2}}\Big{)}O_{l}\epsilon_{-}.$
(17)

The scalar product here is also not equal to zero because
$\delta\beta_{l,l-2}^{2}\neq\delta\beta_{l-2,l}^{2}$. This leads to the
spurious result that the modes $EH_{l-1}$ and $HE_{l-1}$ mix within a fiber.
Prior works [12] are incomplete as they overlook the issue of non-Hermiticity
and the associated problem of non-orthogonality and its erroneous
implications, as demonstrated here.

###  3.2 Remedy for the non-Hermitian matrix $H$

A way to get around the above difficulty (that is, to preserve orthogonality)
might be to rewrite the non-Hermitian matrix $H$ defined in the space spanned
by the states: $(l,1),(l+2,-1)$ of the same $J$ value, $l+1$, as

$H=M+R$ (18)

where

$M=(H+H^{\dagger})/2$ (19)

is a Hermitian matrix and

$R=(H-H^{\dagger})/2$ (20)

is an anti-Hermitian matrix (with diagonal elements equal to zero). We
subsequently consider the eigenstates of $M$, treating the matrix $R$ as an
error matrix.

Matrix $M$ has each of its two off-diagonal elements equal to
$\delta\beta_{l,l+2}^{{}^{\prime}2}=(\delta\beta^{2}_{l,l+2}+\delta\beta^{2}_{l+2,l})/2$.
The eigenstates of $M$ have the same expression as those in Eqs. 13 and 14,
except that $\delta\beta^{2}_{l,l+2}$ and $\delta\beta^{2}_{l+2,l}$ are each
replaced with their mean value, $\delta\beta_{l,l+2}^{{}^{\prime}2}$.
Consequently, the right-hand-side of Eq.15 now equals zero, as expected for
the eigenstates of a Hermitian matrix. For the $J=l-1$ case, where the space
is spanned by the states, $(l,-1),(l-2,1)$, similar results obtain.

Hitherto, we had suppressed the radial index $m$. We assume now that index m
equals 1 for the $(l,\pm 1)$ state, while the state $(l\pm 2,\mp 1)$ is
permitted to have any value $(1,2....p)$ for the radial index denoted
$m^{\prime}$ (the derivation above tacitly assumed one specific value of
$m^{\prime}$). Allowing for more than one value of $m^{\prime}$ leads to the
expansion of the $2~{}x~{}2$ matrix $H$ into a $(p+1)~{}x~{}(p+1)$ matrix,
where $p$ denotes the maximum permitted value of $m^{\prime}$; parameter $p$
is fiber dependent. It can then be shown that the eigenstates specified in
Eqs. 13 and 14 and Eqs. 16 and 17 involve a summation over $m^{\prime}$ on the
second term of the right hand side from $m^{\prime}=1$ to $m^{\prime}=p$. This
summation over $m^{\prime}$ is consistent with a perturbation series expansion
over a complete set of states, labeled by $m^{\prime}$ for fixed topological
charge. Note further, in Eqs. 11 and 12, $F_{l}$ will correspond to $m=1$ and
$F_{l+2}\rightarrow F_{l+2}^{(m^{\prime})}$ will be $m^{\prime}$ dependent.

####  3.2.1 Error matrix $R$

The matrix $R$ in Eq. 18 may be deemed an error matrix (Eq. 20) as it
represents the deviation from full Hermiticity now captured in the Hermitian
matrix $M$. More specifically, error E may be defined as the ratio of the
magnitude of the off-diagonal element of the $R$ matrix
($=(\delta\beta^{2}_{l,l+2}-\delta\beta^{2}_{l+2,l})/2$) to the magnitude of
the off-diagonal element of the $M$ matrix
($=(\delta\beta^{2}_{l,l+2}+\delta\beta^{2}_{l+2,l})/2)$). For the step-index
fiber, where $n^{2}(r)=n_{1}^{2}(1-2\Delta f(r))$ and $f(r)$ is a step-
function at r=a, where $a$ is the radius of the fiber core (see Section 2), we
can easily evaluate the matrix elements, noting that $\partial f(r)/\partial
r=\delta(r-a)$, and $F_{l}(r)$ is the familiar Bessel function of the first
kind, $J_{l}(p_{l}r)$; parameter
$p_{l}=\sqrt{k^{2}n_{1}^{2}-\tilde{\beta}_{l}^{2}}$, where $\tilde{\beta}_{l}$
is determined from the characteristic equation [1]. For fiber parameters,
$a=25\mu m,~{}n_{1}=1.461,~{}n_{2}=1.444$, and wavelength $\lambda=1.55\mu m$,
we find the error E to increase from 10 to 25% as $l$ is increased from 1 to 4
for $m=1$ and the single case of $m^{\prime}=1$. We further find that
numerically $\delta\beta^{2}_{l+2,l}$ in Eq. 10 is of the same sign as
$\delta\beta^{2}_{l,l+2}$, but consistently larger in magnitude, irrespective
of the value of $l$ and $m^{\prime}(\leq p)$, implying matrix $H$ is always
non-Hermitian. The same holds true in the $J=l-1$ case.

###  3.3 Discussion

The space spanned by the four states: $\pm l,\pm 1$ (in the $L,S$ notation)
has been considered by a number of authors in the past in the context of
polarization-induced corrections to the propagation constants of the scalar
OAM modes (see, e.g., [3, 4, 8], and also [1] in the context of $LP$ modes).
The reason the perturbation formulation fails here is that venturing outside
this space triggers a non-Hermitian matrix because the off-diagonal elements
like $<\vec{\tilde{e}}^{(l+2,-1)}_{t}|V|\vec{\tilde{e}}^{(l,1)}_{t}>$ and
$<\vec{\tilde{e}}^{(l,1)}_{t}|V|\vec{\tilde{e}}^{(l+2,-1)}_{t}>$ in the case
of $J=l+1$, are not equal (see Eqs. 11 and 12 above). Casting the polarization
term of Eq. 1 as a polarization interaction operator, $V$, appears to be
applicable only to the space spanned by the above four OAM modes (with a fixed
magnitude of topological charge), where the propagation constants of the
individual modes (of the same topological charge) are changed due to different
polarizations ($\vec{\epsilon}_{\pm}$ ), in close analogy to atomic physics
where the energy levels are changed on account of $\vec{L}.\vec{S}$ coupling.
However, its extension to generate the polarization-induced field component
(see Eqs. 9, 18, and 19) fails as it leads to misleading conclusions and
numerical errors that can be significant. In other words, _polarization-
induced interaction, strictly speaking, is a perturbation internal to an OAM
mode within a fiber. While it successfully accounts for the modal propagation
splitting due to the spin orbit interaction, it cannot be treated as an
external perturbation acting on the (primary) OAM field of the vector mode to
generate the accompanying (secondary) polarization-induced OAM component._ In
fact, starting from Eq. 9, it is explicitly shown in [10] that the second
component in Eq. 9 in fact corresponds to a _modified_ OAM field, where the
intensity pattern of the traditional OAM mode, e.g., the radius of the
intensity donut ring, expands or shrinks, depending upon whether the
polarization is aligned or antialigned with the OAM.

##  4 Summary

We have reviewed the inherent polarization-induced interaction as a
perturbation to explain the differences in the propagation constants between
the vector OAM modes $HE_{l+1,m}$ and $EH_{l-1,m}$ in an optical fiber. The
transverse fields are eigenstates of the total angular momentum operator,
$J=l\pm 1$. Similar results hold for the degenerate vector modes,
$HE_{-l-1,m}$ and $EH_{-l+1,m}$, which correspond to $J=-l\mp 1$.
Mathematically, the propagation constant differences between the vector modes
can be accounted for by treating the polarization term within the vector wave
equation as a perturbation defined in the space of the four OAM states: $(\pm
l,\pm 1)$. However, its extension as a perturbation into the expanded space
incorporating the polarization-induced OAM states $(l\pm 2,\mp 1)$ generates a
non-Hermitian matrix with serious, misleading and physically incorrect
implications. We conclude therefore that polarization interaction acts
internally within a given vector mode to generate the change in the
propagation constant, but cannot strictly be treated as a perturbation
operator to account for the polarization-induced field (the secondary
component of the vector OAM modal field). Instead, a straightforward, direct
analysis of the analytic expression for the polarization induced field reveals
it to be a modified version of the traditional scalar OAM field [10].

## References

  * [1] Allan W. Snyder and John D. Love, _Optical Waveguide Theory_ Chapman and Hall (1983).
  * [2] A.V. Dooghin, N.D. Kindikova, V.S. Lieberman, and B. Ya. Zel’dovich, ”Optical Magnus Effect”, Phys. Rev. 45, 8204-8208 (1992).
  * [3] A.V. Volyar, V. Z. Zhilaitis, and V. G. Shvedov, ”Optical Eddies in Small-Mode Fibers: II. The Spin-Orbit Interaction”, Optics and Spectroscopy 86, 593-598 (1999).
  * [4] C.N. Alexeyev, M.S. Soskin, and A.V. Volyar, ”Spin-orbit interaction in a generic vortex field transmitted through an elliptic fiber”, Semiconductor Phys. Quantum Electron. Optoelectron.3, 501-513 (2000).
  * [5] R. Bhandari, ”Orbital Angular Momentum (OAM) Mode Mixing in a Bent Step Index Fiber”, IEEE Photonics Journal, vol. 11, no. 3, art. no. 7203421, June 2019 (DOI:10.1109/JPHOT.2019.2920097).
  * [6] A. S. Davydov, _Quantum Mechanics_ , Pergamon Press (1965)
  * [7] L.I. Schiff, _Quantum Mechanics_ , McGraw Hill (1955)
  * [8] D.L.P. Vitullo, C. C. Leary, P.Gregg, R. A. Smith, D. V. Reddy, S. Ramachandran, and M. G. Raymer, ”Observation of Interaction of Spin and Intrinsic Orbital Angular Momentum of Light”, Phys. Rev. Lett. 118, 083601 (2017).
  * [9] R. Bhandari, ”Spin Orbit and Contact interactions in Orbital Angular Momentum Modes in a Fiber”, Proc. of _OSA-Frontiers in Optics/Laser Science_ , September 2019, Paper JW4A.122.
  * [10] Ramesh Bhandari, ”Nature of the orbital angular momentum (OAM) fields in a multilayered fiber,” OSA Continuum 4, 1859-1874 (2021)
  * [11] S. Ramachandran, P. Gregg, P. Kristensen, and S.E. Golowich, ”On the Scalability of Ring Fiber Designs for OAM Multiplexing”, Optics Exp, 23, 3721-3730, February, 2015.
  * [12] P. Gregg, P. Kristensen, A. Rubano, S. Golowich, L. Marurucci, and S. Ramachandran, ”Enhanced Spin Orbit Interaction of Light in Highly Confining Optical Fibers for Mode Division Multiplexing”, Nature Comm., Oct 2019; https://doi.org/10.1038/s41467-019-12401-4.
  * [13] B.C. Sarkar, P.K. Choudhary, and T. Yoshino, ”On the analysis of a weakly guiding doubly clad dielctric optical fiber with an annular core”, Microw. Opt. Techn. vol. 31, no. 6, pp. 435-439, Dec. 2001.
  * [14] C. Brunet, B. Ung, P. Bélanger, Y. Messaddeq, S. LaRochelle and L. A. Rusch, ”Vector Mode Analysis of Ring-Core Fibers: Design Tools for Spatial Division Multiplexing,” in Journal of Lightwave Technology, vol. 32, no. 23, pp. 4648-4659, 1 Dec.1, 2014, doi: 10.1109/JLT.2014.2361432.