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

[Jonathan Morton]

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