[Ecn-sane] SCE receiver-side vs. sender-side response

[Ecn-sane] SCE receiver-side vs. sender-side response

[Holland, Jake]

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

Re: [Ecn-sane] SCE receiver-side vs. sender-side response

[Jonathan Morton]

> On 17 Mar, 2019, at 12:25 am, Holland, Jake <jholland@akamai.com> wrote:
> 
> 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.

Yes, I think you've got the right idea here.

> 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.

Using the urgent-pointer field is indeed another possibility, since URG is never legally set on pure acks and is rare on data segments as well (FTP uses it), and the field is unused with URG cleared.  So the need to send both URG data and SCE feedback at the same time is a rare corner case but shouldn't be too difficult to code around.

I think there may still be a problem with paranoid middleboxes erasing the information in that field when URG is cleared, probably because it could be used as an exfiltration channel.  These may be the same set of paranoid middleboxes that erase unknown TCP options.  But this should both be detectable by the new flag being set while the field stays cleared, and basically harmless because there is that fallback to standard ECN - provided the affected packets are not actually dropped rather than just sanitised.

> 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.

This is not inherently a problem, because the receiver can act on congestion information a full RTT before the sender; assuming the receiver is actually controlling the congestion window, halting the advance of the right edge is equivalent to snapping the cwnd completely shut (to zero) at the sender based on the same information.  This is a more aggressive response than any real congestion control algorithm exercises.

> - 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.

As long as the receiver-side congestion control is less aggressive about growth and more aggressive about shrinking than the sender-side, the former will control the effective congestion window.  Of course, it could be that the sender uses NewReno which is as meek as a lamb about growth (one MSS per RTT once out of slow-start), and then a receiver-side algorithm may be acting on congestion signals relevant for a much smaller window than it has maintained.

So that is a potential complication.  A mechanism might be needed to infer the sender's cwnd from timestamp information and feed that into the receiver cwnd calculations.

It might also be best to engage the more limited rwnd only when SCE information warrants it, and leave the responses to CE and loss entirely to the sender.  This would still require maintaining the on-wire rwnd small enough to be engaged at relatively short notice, yet large enough to accommodate reasonable sender-side cwnd evolutions, using inferment of the current cwnd as a guide.

 - Jonathan Morton