Re: WG chair on buffer exhaustion

> 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."
> 
I would suggest the following section:

Section TBD ULP Flow-control

    The ULP is responsible for providing flow control for
    untagged messages. The Data Source MUST know that it
    is authorized to send an untagged message before sending
    it. The Data Sink MUST know the maximum number of untagged
    messages that it has authorized for reception on a DDP
    Stream or set of streams.
    
    The method by which the Data Source and Data Sink ULP
    reach agreement on this limit is outside the scope of
    this specification. Possible methods include dynamically
    negotiated credits, session negotiated credits and
    fixed limits imposed by the ULP specification.
    
    The Data Sink SHOULD provide sufficient buffers for
    the untagged messages that it has authorized. However,
    it is not required to do so by pre-committing a buffer
    for each valid QN/MSN combination. However the local
    interface MUST allow the Data Sink ULP to pre-specify
    the buffer for each valid QN/MSN combination.
    
    Receipt of an untagged message that was not authorized
    by the Data Sink ULP SHOULD result in termination of the
    DDP Stream. The local interface may allow authorization
    of untagged messages for a specific stream and/or for
    a group of streams.
    
    Receipt of an untagged message that was authorized, but
    for which there is no available buffer, MAY result in
    termination of the DDP Stream. However, implementations
    MAY treat the absence of a buffer for a valid untaged
    message as a local fault. Implementation specific
    procedures to recover from such a fault MAY be used,
    especially if they avoid impacting the remote peer.
    

I believe this specifically takes care of one iSER concern.
The bulk of the allowed untagged messages have CmdSNs, and
are flow controlled for a *set* of streams that belong to a
single session. It would require that a limit be set for
asynchronous messages, but would allow that to be a ULP
constant rather than a dynamically negotiated value.

It also allows for strict and immediate termination of
untagged messages that are bound to simple Receive Queues
or to the RDMA Read Engine. In the latter case, a "soft
limit" approach would seem to be very inappropriate.