RE: WG chair on buffer exhaustion

Do I read into this that you believe that DDP implementations MUST
implement a per stream hard limit on untagged messages ("termination is
a reasonable response")?

If you do, the next question is how fast?  Is it ok to delay the stream
termination under some conditions, until some "extra" untagged messages
have arrived and used buffers?  This might occur if the mechanism for
detecting the hard limit exception depended on counting completions in
software, for example, or if it depended on software to respond to an
exception.

As pointed out earlier in this thread, the mechanism that returns
"credits" for the "hard limit" can become an additional burden for
implementations, depending on how that is done.  A "loose" credit check
and/or update can significantly reduce that burden.  

It is not clear how much guidance the DDP security specs need to provide
on this issue, other than to say something to the effect of: "Here is an
issue, make sure that your implementation, or upper interface and ULP
can deal with it."  Seems like getting too detailed may provide
unnecessary restrictions on implementations.

Paul R. Culley
HP Senior Fellow
281-514-5543


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: Monday, July 21, 2003 2:03 PM
> To: [email protected]
> Subject: [rddp] 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.
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>