Re: WG chair on buffer exhaustion

I recall several on this WG have agreed that the
current DDP text that I pointed out is severe.
Let's just fix that text to address the WG concerns.  

You had earlier argued that DDP text is fine the way
it is, now you're proposing a  _lot of_ text that
does not fix the text the WG had a problem with.

No amount of wordsmithing that does not fix the original
text will resolve the issue I had brought up.  Besides, I do 
not agree with all the text you suggest.

Needless to say, I prefer the text I recommended.
--
Mallikarjun

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

----- Original Message ----- 
From: "Caitlin Bestler" <[email protected]>
To: "Mallikarjun C." <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, July 29, 2003 1:51 PM
Subject: Re: [rddp] 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.
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>