[Cake] Control theory and congestion control

[Jonathan Morton]

>> So what you might have is an ELR queue happily controlling the cwnd based on the assumption that *it* is the bottleneck, which until now it has been.  But *after* that queue is another one which has just *become* the bottleneck, and it’s not ELR - it’s plain ECN.  The only way it can tell the flow to slow down is by giving “fast down” signals.  But that’s okay, the endpoints will react to that just as they should do, as long as they correctly interpret the most restrictive signal as being the operative one.
> 
> how would the ELR queue know that things should slow down? If it isn't the bottleneck, how does it know that there is a bottleneck and the flow that it's seeing isn't just the application behaving normally?

The ELR queue doesn’t know anything about the other one, and doesn’t need to.  The *new* bottleneck sends ECN signals, which override the ELR “hold" signals (which are sent using the same two bits in the TOS byte).  ELR endpoints react to both ECN and ELR signals.  The send rate reduces, and the ELR queue is no longer saturated, ergo no longer the bottleneck; it then stops sending “hold”.

So it’s possible to have two queues which simultaneously believe they are the bottleneck, but only as a transient condition.  In fact, we often have that today, when we insert a shaped ingress queue *after* our last-mile link.

Please read the post entitled “Explicit Load Regulation”, which I wrote after spending several hours figuring out the right way to do it, and try to keep up.

>> On many links, light traffic such as e-mail will disturb the balance too little to even notice, especially with flow isolation.
> 
> This depends on the bandwidth and the type of e-mail. It's very common for single e-mails in an office environment to be several MB (not the ones with big document or spreadsheet attachments, but the things like holiday party announcements and other similar things)

But you’re not getting those continuously, are you?  Or, if you are, it’s time to reconfigure the office’s spam filter.

So while a *big* email is coming in, the bandwidth available to other flows might be disturbed.  ELR will help to adjust to that, just like ECN does.  Then it’ll adjust back when the disturbance has gone, and resume the steady state.

This is not rocket science.  This is 1950s locomotive technology.

> e-mail to a mobile device can have a rather significant impact on cell or wifi bandwidth.

Yes - at least on mobile, I’d agree - but that’s one case.  There are others.

And even on a mobile connection, it’s potentially useful to have a well-defined steady state, when conditions are right for it.  It’s harder to get to those conditions in a wireless environment, but not impossible, especially for rate-limited subscriptions.

As they say, don’t ban steak just because a baby can’t eat it.

>> Of course, as with any speculation of this nature, simulations and other experiments will tell a more convincing story.
> 
> I have a significant distrust of simulations at this point.

Hence “and other experiments”.

But it’s also likely that simulations will help to understand the emergent behaviour of something like ELR, before anyone expends too much effort on implementation and standardisation.

 - Jonathan Morton