Target switching in hierarchical `LSTF`/`EDF` and `SJN`

[polybeandip]

Before reading this issue, it would be helpful to familiaize yourself with the EDF in our glossary of scheduling policies.

Consider the following DSL program; while it's specific to EDF, the same discussion can be had about SJN.

classes A, B, C;

rr_A_B = rr[A, B];

policy = edf[rr_A_B, C];

return policy

Question 1: when pushing a packet, what rank do we give it's associated pointer in the root PIFO?

Perhaps using the packet's "slack" is a good choice? let's go with that for now!

Suppose we encounter the following sequence of packets (before performing any pops)

# Notation: (X_i, j) is the ith packet from flow X, with slack j
(A_1, 1), (A_2, 2), (A_3, 3), (B_1, 1000), (C_1, 4)

Flushing our PIFO tree yields

A_1, B_1, A_2, C_1, A_3

Question 2: is this right?

Notice how packet B_1 was popped before every packet other than A_1 despite having a drastically larger slack than them.

Question 3: is this strange or a problem? I think B_1 could maybe overtake A_2 and A_3 but passing C_1 feels wrong. Similarly, A_3 losing to C_1 seems odd.

In general, it seems policies that use properties inherent to packets have confusing behavior when realized on trees, similar to our previous discussion on PIEO trees. There, we got away with this because target switching would only happen between ripe packets (which we deemed okay); here, all packets and internal references are always visible.

[anshumanmohan]

Happy to go some other way of course, but I kinda think that a policy like edf should totally smother any sub-policies and just enforce slack-based prioritization.

So, your policy above is the same as:

edf[A, B, C]

Your problem is very interesting, but, like it sorta reads like the user didn't really know what they wanted! In general I do think it's okay if certain hierarchical compositions cancel each other out, or smother a child, or whatever.

[KabirSamsi]

Discussing our attempts to resolve this in #55.