For some reason we aren't getting any debug logs with NoLimit runs. Figure out why for monitoring and to compare against HIPRI (which should be identical but isn't).

These can fail sporadically (e.g. iptables rule changes). We should retry a few times before giving up.

I am not seeing approval violations with inc-nl since the QoS value was fixed. What's odd is that the fix should not have impacted inc-nl. This could be run-to-run variance. Need to investigate.

Here is an example run.

There is enough bandwidth for all of the demand to be met, so what's going on? One suspect thing is that the client processes hit 100% CPU utilization at some point during the run. That's a starting point.

In results/2021-09-03-qoschurn-smarter-routing, LOPRI clearly has higher latency than HIPRI, but in results/2021-09-10-retry-w-loadshed, qflip_lr seems unaffected by the use of LOPRI. Looks like setting up the higher latency QoS failed, for whatever reason.

Low priority: we already have results/2021-09-03-qoschurn-smarter-routing.

Seen today

cluster-agent: heyp/cluster-agent/allocator.cc:361: auto heyp::(anonymous namespace)::DowngradeAllocator::AllocAgg(absl::Time, const proto::AggInfo &, proto::DebugAllocRecord::DebugState *)::(anonymous class)::operator()() const: Assertion `false && "frac_lopri >= 0"' failed.

frac_lopri is likely a NaN since I can't think of a reason it would end up < 0. Instead of treating this a fatal error, we should issue a warning and clamp the value into [0, 1].

Uniform is too accurate—10 samples is not going to give that accuracy all the time—something is going wrong. Steps to try: look at the raw limit values, look at the uniform dist estimator.

In 6a00e27 we made shutdown errors non-fatal since they occur often and the logs should still be usable. If we can make shutdown more robust, we should make it fatal again (except for debugging).

As of 4864a6d, I see the following usage for inc-nl when running experiments/web:

The usage should be much higher (starting out much closer to the dotted line and gradually decreasing). If I change num_AA_backends to 1 then the issue goes away:

Not sure what the problem is. We might have too few connections, too many connections, a bottleneck in Envoy, or some issue with the Envoy config.

In the below image, we plot a vertical line whenever the allocation at a host is changed.

Notice on the right that the lines get "fatter". This could be caused by the cluster agent waiting on one host agent before transmitting a request to the next which is less than ideal. We should buffer one response to each host enforcer and send them in parallel. If a host is unresponsive, then the new limits can just overwrite the buffered one since it's stale at this point anyway.

It seems like envoy's admin interface is not getting its port number plumbed through correctly.

@@ -690,4 +732,4 @@ admin:
   address:
     socket_address:
       address: 0.0.0.0
-      port_value: 5001
+      port_value: 0

I don't have the pictures on hand, but I've seen cases where rate limit = 0 at some point during the run. If I recall correctly, this was taking place in an experiment where we set host rate limits explicitly to be nonzero.

With the new dual-network setup, we need to check that retransmissions are counted correctly.

Check whether downgrade selectors are shared between FGs. Now that we have stateful selectors (e.g. hash ring based), this could lead to problems.

This would make the flow markers consistent with what we get from the cluster agent. As of 970a031, it's unnecessary because we ignore the field. Low priority, but consistency may reduce confusion down the line.

This might be working properly now, but we should double check.

Host-agent is currently not controller the interface that actually talks to AA and WA. We don't care about the other interface.

The vfortio VMs have an old ss binary installed. We can just steal a newer one from current alpine and install it with fortio and host-agent.