WG chair on buffer exhaustion

The heated debate on whether lack of availability of a buffer for
an untagged message causes immediate termination of the DDP stream
on which it arrived caused some additional email behind the scenes
in addition to what's been on the list.

With my WG chair hat on, here is what I believe to be the correct
resolution of this issue:

The request to do something other than immediately terminate
a stream when a message shows up that does not have a pre-queued
untagged buffer to receive it does not require that DDP tell
TCP not to ACK the message; an implementation could choose to
do that based on inter-layer implementation optimizations,
but had better do so very rarely.  Alternatively, a DDP
implementation could choose to have some "hidden" resources
in its back pocket that might involve a less efficient receive
path (e.g., receive the errant message to a hidden kernel buffer
and then copy to an application buffer when it becomes available)
- again, this would need to be a rare occurrence for obvious reasons.
This sort of approach is more robust than having TCP not ACK, as
it avoids propagating a host problem into the network and puts the
performance penalty for the implementation problem (should
have had a buffer available, but didn't) squarely on the system
that had the problem.

I would prefer to see the "hidden [kernel] buffer" approach
described as an example rather than the "TCP doesn't ACK" approach.
Among the other problems with "TCP doesn't ACK" is that it creates
a nasty head-of-line blocking problem that affects all traffic
on the connection, not just the untagged traffic that is facing
the resource shortage.

OTOH, if the ULP has set a hard limit on the number of untagged
messages that can come in from a specific stream, and that stream
exceeds the limit, this is evidence that the counterparty isn't
following the rules, and termination of the stream is a reasonable
response.  In the particular scenario that John raises below, the hard
limit would need to be set high enough to accommodate error/special/
emergency conditions, and statistical/shared buffer provisioning would
probably be used to avoid having to provision buffers for simultaneous
occurrence of error/special/emergency conditions on all inbound streams.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> >
> >On Wednesday, July 16, 2003, [email protected] wrote:
> >
> >>Again, I think that Mallikarjun stated things correctly.  There are
> >>important applications which can only correctly predict the number of 
> >>buffers needed in non error/special/emergency conditions.  When 
> >>error/special/emergency conditions occur, the number and urgency of the 
> >>handling is problematical.