Subject: [rddp] Pre-posting/authorizing receive operations

From: Caitlin Bestler <[email-masked]>
Date: Thu, 27 Mar 2003 16:11:14 -0600

I'd like to expand a bit on the issue of pre-posting, or at
least pre-authorizing of receives.

I agree that requiring the buffers to be registered and
pre-allocated is incorrect. However, I believe that it is
vital that the receiving ULP pre-authorize each untagged
message and that excess untagged messages will terminate
the DDP Stream rather than consuming system resources and
placing *other* DDP Streams at risk.

With both the MPA/TCP and SCTP mappings, the transport/DDP
interface received DDP Segments can be pushed to the DDP
layer. The DDP layer can be expected to place the received
data immediately, i.e. the LLP has no further need to hold
the buffer after the "push" call completes.

Without pre-posting of receive buffers the receiving DDP
would be obligated to buffer untagged data until the ULP
requested it.

This is not something that a DDP implementation should be
required to do. That is my justification for saying that
a DDP implementation MAY require the ULP to pre-post a
buffer for each receive operation.

But even if a DDP implementation is willing to use a common
buffer pool, it should not allow that pool to be drained by
a single remote peer. Requiring the local ULP to at least
pre-authorize the receive operation guarantess that there
is ULP level flow control on untagged messages. If the local
peer attempts to authorize too many receive operations
without supplying buffers, the DDP implementation can
refuse. This may require the DDP Stream to be aborted --
but the impact is limited to the DDP Stream causing the
problem. Without pre-authorization of receives, the DDP
Stream that comes up empty on system buffering may not
be the guilty party that drained the pool.

The reason for not requiring the buffer to be pre-registered
is simple. The ULP may have no need to expose that memory
for any longer than the single receive operation. The DDP
layer already has all of the information required to
"register" any buffer for the duration of the read.

Any requirement that the buffer be pre-registered would be
based upon the local implementations cost of dynamically
reqistering the memory. While this may be a valid concern in
designing a local interface, it is not relevant for
specifying the portions of the local interface that MUST be
present to ensure interoperability.

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