Re: Error code returns for DDP tagged buffer messages

On Apr 27, 2004, at 12:51 AM, [email protected] wrote:
>
>
> On the MSN errors, your answer presumes there is a fixed queue size 
> which there may or may not be. There also isn't a value in 
> distinguishing between these two errors. A message arrived and there 
> was no buffer.
>
>
There is a valid distinction between "Invalid MSN: you should not have 
sent
that message" and "Oops I don't have a buffer, sorry about that."

As previously discussed while covering the implications of SRQs, for 
RDMA
based ULPs to work, there MUST be a concept of a "valid MSN". But it is
possible for an implementation using SRQs to be unaware of this 
limitation
at the DDP layer. It is also highly plausible that the DDP layer will 
not know
how many buffers are available to it, merely whether it can allocate 1 
(in
the case of arrival order allocation) or n (in case of serial order 
allocation).

But I believe this issue has already been settled in the security 
discussions.
Handling of per-stream credit violations by either the ULP or Privileged
Resource Manager implies that the implementation is only required to
detect such violations *promptly*, not synchronously.

While I remain a strong proponent of catching these violations 
synchronously,
making the existence of an SRQ transparent to the ULP peer, clearly
this will not be a protocol mandate. The only requirement is that the
deterministic response to such overruns not be forced upon all
applications that want to use SRQs. But inherently delayed detection
of the condition is legitimate.

Therefore we cannot *require* that the generated error distinguish 
between
"Invalid MSN: you should not have sent that message" and "Oops, sorry
no buffer, I'm not sure who goofed".

The question then becomes whether it is useful for implementations that
*can* distinguish (as almost any would when using a plain RQ) to
return the separate error for informative purposes.

My inclination is that this is valuable, and unlike the "Invalid STag" 
error,
provides virtually no information to an attacker. Theoretically, it 
allows
an attacker to probe how many untagged message credits a stream had,
but each probe tears down the stream. It's not terribly important 
information,
and can probably be inferred more simply by just eavesdropping.


--
Caitlin Bestler
http://asomi.com/