WG chair on buffer exhaustion (again)

With WG Chair hat on, let me step into this debate:

> > 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."
> 
> If the local interface has allows the DDP endpoint to know the valid
> range of MSNs on a stream (which it will for simple Receive Queues at
> the minimum) then it definitely SHOULD NOT consider the lack of a
> buffer for an *invalid message* to be "an exception".

Two issues are getting conflated here, and need to be kept separate:
- Mallikarjun's issue involves statistical (under-) provisioning of buffers,
	so that an otherwise valid untagged message shows up without a
buffer
	available to receive it (if the implementation had done worst-case
	provisioning, there would have been a buffer available).  I believe
	there is WG rough consensus that this is an exceptional condition
	that does not need to immediately cause the termination of the DDP
	stream that sent the message, but it SHOULD not occur frequently.
	Mallikarjun's proposed text is close enough to what's needed for
this.
	This condition could happen even on a simple Receive Queue if
	statistical (under-) provisioning is being used.
- Caitlin's issue involves a peer violating a fixed per-DDP-stream limit on
	the number of untagged messages allowed .  At the moment, the exact
	need and nature of such limits is still an open issue that needs to
be
	resolved in the context of the security draft.  When we have it
resolved
	there, additional text will (probably) get driven into the DDP
draft.
	If the issue is resolved in the manner Caitlin advocates, then
	her proposed text is certainly a candidate for what the DDP draft
	will need to say, but at the moment, the issue is open, and the
	DDP draft should not change what it says about this issue until
	it is resolved in the context of the security draft.

Also, I've seen some confusing references to iSER and assumptions about
local interface and resource sharing model.  Shared Receive Queues have
*not* been approved/adopted by this WG (and can't be until we get the
resource sharing issue [2nd bullet above] resolved).  To the extent that
iSER requires Shared Receive Queues and can't cope with any other local
resource model, it's probably made an overly restrictive design assumption
that it's designers would be well-advised to reconsider, keeping in mind
that the Hilland verbs draft is at best an *example* of a local interface
to RDDP; it should not be viewed as normative functional requirements on
that local interface.

With luck, that's useful clarification, but feel free to ask if anything
above doesn't make sense ...

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
----------------------------------------------------