[WIP] net: tcp: Explicitly manage TCP receive window.

[pfalcon]

Challange the existing situation that "if application buffers data,
it's the problem of application". It's actually the problem of the
stack, as it doesn't allow application to control receive window,
and without this control, any buffer will overflow, peer packets
will be dropped, peer won't receive acks for them, and will employ
exponential backoff, the connection will crawl to a halt.

This patch adds net_context_tcp_recved() function which an
application must explicitly call when it processes data, to
advance receive window.

Jira: ZEP-1999

Change-Id: Id7255df3d4898e289a2d20e7a02fd5f3f8f05291
Signed-off-by: Paul Sokolovsky paul.sokolovsky@linaro.org

[pfalcon]

This is trivial implementation of TCP receive window handling, to back discussion on how to do it properly in JIRA: GH-3440 and on mailing list: https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-April/007621.html

[lpereira]

Maybe @andyross will want to take a look here.

[pfalcon]

@lpereira : Thanks for the ping. I actually wait for continuation of @andyross' review on #26 , and there's another which warrants his look ahead of this as it touches code written by him: #137.

[andyross]

This seems like the wrong behavior. I mean, yeah, it's a stack bug on the other side and they blew the limit you set. Nonetheless, they transmitted the data and we received it without overflow. That's not an error condition, we should present the data to the app and attempt to continue.

I mean, just to geek out: I went to get a quote for the "be conservative in what you emit but liberal in what you accept" maxim and was reminded by wikipedia that it's literally from the TCP RFC (thus "Postel's Law"):

TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

[pfalcon]

Well, that's a dream scenario of any DoS attacker - they send you useless stuff which you try to hold, while dropping real precious things, because all your hands are tied with useless stuff.

[andyross]

Really not liking this API. For one, it's asymmetric with respect to other net_context implementations. You need to know that your context is a TCP connection and use it differently than you do other types. Secondly, it's non-standard: other OSes don't do anything like this.

Third, I don't see value it provides. The only reason TCP windows exist (for our purposes, anyway) is to prevent buffer overflows in the receiver. I don't see how this helps the app do that.

If you want a way for the app to explicitly set windows, then (1) make it optional and (2) make it abstract. How about something like Linux's TCP_WINDOW_CLAMP sockopt instead?

[pfalcon]

You need to know that your context is a TCP connection and use it differently than you do other types.

You need to know the type of a socket - STREAM or DGRAM to work with it properly.

Secondly, it's non-standard: other OSes don't do anything like this.

What OSes do you mean here? Those which can no longer work with a gigibyte of RAM, all those linuxes, windowses, and macosxes? The mechanism presented in this patch is a direct translation of the same mechanism of lwIP, which is not an OS, but a portable reusable IP stack which works with almost any RTOS out there, a golden standard in embedded IP stacks, used in probably 80% of projects, tested and tried for a decade or two.

All these points were given in detail in the RFC which is by the link given above: https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-May/007637.html .

Note that in further discussion of that IRC, I subscribed to a research of doing it "how big OSes do": https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-May/007637.html . But until that code is written and tested to give the needed effect, the simple changes presented in this patch are the only ones needed to correctly manage TCP control flow.

The only reason TCP windows exist (for our purposes, anyway) is to prevent buffer overflows in the receiver. I don't see how this helps the app do that.

Please see GH-3440?focusedCommentId=18206&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-18206

[nashif]

what is the status of this one?

[nashif]

Can this be closed?

[pfalcon]

Thanks for removing 1.9 milestone. As this is a serious issue (blocker for large TCP xfers), I'd prefer to close this when an alternative patch will be available (which I hope to work on soon).

[pfalcon]

Superseded by #1002