Re: WG chair on buffer exhaustion

David,

Sorry it took me a while to respond to this discussion.  Also,
I will only have sporadic access to email for the rest of the week.

I guess I generally agree with the direction you're suggesting.
I had earlier suggested certain DDP text changes to address
this issue.  Based on your input, here's one more attempt to 
address the same.  

I hope this is acceptable to everyone since most seem to agree 
that the current DDP text is too restrictive/severe in this area.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email protected]


The current relevant text is:
section 3.2 (Protocol Overview),
    " Note, however, that
        the ULP needs to address flow control issues because if a DDP
        Message arrives for an Untagged Buffer without an associated
        receive ULP buffer, the DDP Message is dropped, the DDP Stream
        is disabled for reception, and an error is reported to the ULP
        at the Data Sink."

and section 9.1  (Errors detected at the Data Sink).
    "   2.  The QN and MSN have an associated buffer that allows Placement
       of the payload."

My suggestion is to change the text along the following lines:

Section 3.2 to:
    " Note, however, that the ULP needs to address flow control issues.  Any 
      ULP that runs on DDP SHOULD consider the lack of an associated receive 
      buffer to place an inbound Untagged Message of the ULP as an exception."

and section 9.1 to:
    " 2. The QN and MSN have an associated buffer that allows Placement of the 
           payload. In order to gracefully deal with transient buffer exhaustion, some
           DDP implementations MAY choose to consider lack of an associated receive
           buffer to be not an error , such implementations MUST however ensure
           that the affected DDP Segment is eventually recovered in an implementation-specific 
           (as an example, by relying on DDP private buffers) way that guarantees 
           ULP-transparency.  However, the ULP SHOULD NOT rely on the DDP 
           layer gracefully handling this situation on a regular basis."





----- Original Message ----- 
From: <[email protected]>
To: <[email protected]>
Sent: Monday, July 21, 2003 12:02 PM
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
>