RE: [tcpm] Is this a problem?

*If* you were going to solve this problem as a *transport* problem
then you would have to define it in transport terms. I'll attempt
to offer such a description, and show that it is still in conflict
with the application layer problem.

The apparent transport layer issue is that the application does not
know whether the lack of credits are due to lack of receive buffers
or network congestion. The presumption here is that the server is
willing to suffer a bit if the problem is in the network rather
than the client.

The problem is that as long as the client is using TCP over a
conventional stack the receive buffers actually belong to the
OS and not to the client. So the absence or presence of receive
buffers does not really tell us anything about the client's state.
For example the reason the available receive buffering for the
connection is so small might be that the OS or Hypervisor has
swapped the client out.

So the lack of adequate receive windows can have *three* causes:
network congestion, lack of OS buffering resources or failure
of the client to drain the connection. And the latter case can
be a failure of the client to drain the connection that is based
on malice and/or sufficiently sloppy coding that terminating the
connection is justified, or it could just be that the client
is not getting scheduled for OS reasons.

There is no way for the transport layer to distinguish between
any of the latter three cases. There are many reasons for a
lack of receive buffering, and they all look the same on
the wire.

Now you could use a transport that guaranteed availability of
specific buffers that are fully guaranteed. You might even call
it something like Remote Direct Memory Access. But before you
could deploy this solution you would have to convince the clients
to use it. If you are trying to do this as a DoS protection then
you must convince *All* clients to make the shift so that you
can turn off support for legacy modes. If you were to actually
attempt such a project you should not do it with TCP. HTTP would
be far better implemented over SCTP and/or RDMA than over TCP
(if you are willing to ignore the billion or so installed clients).

More generally, while there is some merit in separating feedback
about end-to-end buffer credits from congestion tracking, such
a change would not be a "minor" tweak to TCP. If the market was
willing to make major changes to TCP it would already be using
SCTP instead.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm