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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat