[Bloat] SCE receiver-side vs. sender-side response

["Holland, Jake" <jholland@akamai.com>]

Hi guys,

I was looking through the updates on SCE, and I think this
receiver-driven idea is doomed.  I mean, good luck and it's a neat idea
if it works, but it's got some problems with flexibility:
- you don't want to reduce right edge of window, so you can't reduce
  rwnd faster than data is arriving.
- growing rwnd won't grow cwnd automatically at that rate, so it's only
  a cap on how fast cwnd can grow, not a way to make it actually grow
  from the sender's side.  I think this limits sender's response
  substantially.

So I'd like to get just a quick sanity check on the 3 ways that occur to
me to report the SCE ratio explicitly to sender, because I think that's
going to end up being necessary.  I assume some of these have occurred
to others already, but it would be good to see some discussion:

1. a new TCP option:
As some have mentioned, there are middle boxes known to drop unknown TCP
options[1].  But the nice thing about "backward compatible" means you
don't lose the regular ECE response, so it's no different from not
having the SCE marks, and just degrades gracefully.  So I rate this
viable here because it's an optional bonus, if I'm not missing
something?

2. new TCP header flag:
There's 4 more reserved bits in TCP, so it's not hard to imagine a ESCE
that's either 1-for-1 with extra acks as needed, like L4S's ECE
response, or with a proportion matching the SCE proportional packet rate
on the naturally occurring acks.  (I like the 2nd option better because
I think it still probabilistically works well even with GRO, depending
how GRO coalesces the SCE flag, but maybe there's some trickiness.)

3. new TCP header flag plus URG pointer space:
It's also not hard to imagine extending #2 so that it's incompatible
with URG on the same packet (which mostly nobody uses, AFAIK?), and
using the URG ptr space to report a fixed-point value for SCE rate over
a defined time span or packet count or something.


I can see any of these 3 with or without SYN/SYNACK option negotiation
at startup. (Or even from just setting ESCE, sort of like the ECE
signaling in regular RFC3168 ECT negotiation.)

I do think that to capture the value here, the SCE rate probably has to
get back to sender, but I think there's good options for doing so, and
anywhere it doesn't work, (I think?) it just falls back to regular CE,
which is a nice bonus that comes from backward compatibility.

Any other ideas?  Any pros or cons that spring to mind on these ideas?

Cheers,
Jake

[1] Is it still possible to extend TCP?  (Honda et. al, SigComm 2013)
http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf