Re: [tcpm] New I-D

> Well behaved applications usually SHOULD do this, i
> agree, can't be guaranteed though. Leaving the problem
> to be addressed by the app, does not ensure timeliness
> from the point of view that TCP resources such as
> buffers and connections are scarce and by how much
> etc. The scheme lacks robustness if left to the
> application, and for it to be beneficial, ALL
> applications running on a system should be doing it,
> otherwise there is the weakest link.

So, let me step back.  I should have been more careful.  I think this is
a problem with the draft-not the approach.  That is, I can certainly
understand why a TCP would want to not depend on apps.  But, the text in
the i-d doesn't lead me to that conclusion and I think it is at very
best dubious in some places.

> At first glance, it does seem like an OS resource issue, but TCP
> connections can have data backlogged in their send queues for a
> variety of reasons and for variable amounts of time, i am not sure how
> a protocol unaware OS based solution can make the distinction between
> the network causing the backlog transiently, and a legitimate vs rogue
> receiver causing the backlog etc, i feel that making it TCP protocol
> specific (something designed only for persist state) allows for well
> controlled, granular solution(s) and heuristics to detect specifically
> misbehaving receivers in this scenario.

We are having a terminology problem here.  I meant "OS" as in the thing
that contains the TCP implementation.  I did not mean that an OS could
blindly reap off resources without understanding anything about TCP.

Let me put it this way ... This seems to me to be a TCP
**implementation** issue.  Why should we need to standardize this issue
and not other internal resource contention issues?  Why is this anything
but a very local problem that can be handled by the TCP implementation
in whatever way that implementation chooses?

And, then why is the proposed solution the right one?

allman