Re: WG chair on buffer exhaustion

I think that David has made a useful observation here. Having
the protocol specify that the DDP stream be terminated when
an untagged message is presented to DDP when there is a
lack of an available buffer is a reasonable specification.
What it doesn't prohibit is an implementation from
performing tricks to delay delivery which would
result in the stream termination.

Tricks to delay delivery can include having the transport
have a set of hidden buffers, have the transport intentionally
fail to ACK or close its window, or even have the bottom
layer of DDP have hidden buffering that delays delivery.

In a nicely layered approach the semantics are well defined,
if you deliver an untagged message when there are not
buffers available, the DDP stream MUST be terminated. But
in a complex or sophisticated implementation the lower
layers are free to perform whatever tricks it wants to
delay delivery until buffers are available to prevent
termination, but that is a quality of implementation issue.

I would venture that it is not worth a discussion of the
advantages and disadvantages of such trickery as failing
to ACK. Simply state that lower layers MAY delay delivery
of an untagged message to DDP when no buffers are available,
details are left to the implementation.

	-David


[email protected] wrote:
> 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.
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp