Subject: [rddp] STag Invalidation: local or remote?

From: Caitlin Bestler <[email-masked]>
Date: Thu, 19 Sep 2002 14:26:41 -0500

Why is the STag to be invalidated part of the Send and
Invalidate message, as opposed to it being part of the local
interface's receive operation?

There are several advantages to keeping this a local
interface issue (even if we mandate its existence):

-- It avoids revealing to the Data Source what the reuse
strategy on STags is. Whether or not an STag has been
delivered multiple times should not be relevant to the Data
Source.

-- It reduces the size of the packet by 32 bits. (Ok, this
isn't very much of a benefit).

-- For most protocols, there will be exactly one STag that
could be invalidated anyway. DAFS for example, delivers one
buffer advertisement per request. The DAFS mapping to DDP
would presumably require the response to invalidate that
tag. The point is: if the value to be supplied was known a
priori to the receiving side, why include it in the packet?

Is there a ULP scenario where there is a pool of advertised
buffers that could be invalidated in an unpredictable order?

If there is, I have no problem with the feature as proposed,
but we should capture the justification in the applicability
statement.

If not, I believe it would make sense to shift this feature
from wire-spec to interface-spec.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp