Re: Error code returns for DDP tagged buffer messages

On Apr 23, 2004, at 8:22 PM, Barry Reinhold wrote:

> Clause 9.2 DDP Error Numbers provides the error codes "Invalid STag" 
> and
> "STag not associated with DDP Stream", but the language of the first
> paragraph is not clear enough for me to understand the expectation for
> the following:
>
> Is it the intent to require that a receiver delineate between "Invalid
> STag" and "STag not associated with DDP Stream"? That is, if STag 10 
> was
> valid on stream A but not on stream B, MUST the receiver return "STag
> not associated with DDP Stream?" if a DDP Segment is received on stream
> B with STag 10, or is "Invalid STag" acceptable.

I had interpreted it as *allowing* the receiver to make that 
distinction,
but that given a choice of error codes that are both true the receiver
is free to choose whichever one it desires.

Personally, I see no reason to inform my peer as to whether an
STag might be valid on another stream, so I would always return
the "STag not associated with DDP Stream" error.

In may implementations the STag will indeed have an RNIC scope,
and hence 'Invalid STag' means that the first check (for existence
of the STag) failed, and the second one is used when the PD
check fails.

However, it would be totally valid for STags to in fact have the
scope of the PD. In which case the receiver would only know
that there was no such STag enabled for the endpoint's PD.

>
> This question also applies to delineating between "Invalid MSN - no
> buffer available", and "Invalid MSN - MSN range is not valid". However,
> this is a bit more difficult conceptually as Clause 9.1, item 5 states:
>
>        The legal range is defined as being between the MSN value
> assigned to
>        the first available buffer for a specific QN and the MSN value
>        assigned to the last available buffer for a specific QN.
>
> Which appears to tie "invalid MSN pretty closely to no buffer 
> available.

A local implementation might interpret a buffer that has been authorized
as being "available". In which case the the "no buffer available" might
be used very precisely to mean that although the message had been
authorized there was through an internal slip-up no buffer available.

Generally, however, I think the two are redundant. The term 
"unauthorized"
buffer would be more precise (with the local implementation being free
to assume that a buffer must be authorized if there is a buffer for it).

There have been numerous discussions on this topic and its
implications related to shared receive queues. While it is conceded
by all that the ULP must exercise flow control, and hence there is
indeed an ultimate distinction between an "authorized" untagged
message and an invalid one, there are differing options as to whether
this is something the endpoint should or can easily track.

My position has always been that failure to track per connection
credits creates a security risk where one connection can imperil
other connections. For most multiple-connection scenarios that
is not acceptable. There are, however, distinct scenarioes where
credits are complex and session based. In those cases having
the endpoint attempt to enforce credits is indeed a hinderance.

In any event, for any endpoint that does not share receive buffers
(using plain receive queues) the method of authorizing the
reception of a new untagged message is simply posting
a new buffer to the receive queue.