Subject: RE: [rddp] Some Minimal end-to-end Buffer Rules Required

From: [email-masked]
Date: Mon, 14 Jul 2003 09:35:48 -0600

Caitlin,

This proposed rule below is not practical as the DDP implementation has no information on how many untagged messages the ULP has authorized. To add that information would require constant communication between the ULP and the DDP implementation to relay information about the credits that had been passed to the peer. Such communication would be a performance problem on the backplane. The ULP and not DDP should be responsible for detecting that the peer has overrun its credits. 

What is necessary to protect other connections in a shared buffer pool situation is to deal with the problem of a peer that has tied up excessive numbers of partially filled buffers. The ULP can only see completions, so an attack is possible by sending segments for many messages without completing any message. For instance, in the verbs document, we put an alarm (with threshold settable by the ULP) for excessive incomplete buffers in a receive queue.

Regards,
Pat

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]]
Sent: Saturday, July 12, 2003 10:58 AM
To: Stephen Bailey; [email-masked]
Subject: [rddp] Some Minimal end-to-end Buffer Rules Required

<snip>
I believe the following rules are required for untagged buffers

<snip>
-- Unauthorized untagged messages SHOULD terminate the DDP Stream.
   Failure to terminate an "over credit" DDP Stream MUST NOT imperil
   the availability of resources for any compliant DDP Stream.

<snip>

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 14 Jul 2003 11:44:38 -0500

On Monday, July 14, 2003, [email-masked] wrote:

>This proposed rule below is not practical as the DDP implementation has 
>no information on how many untagged messages the ULP has authorized. To 
>add that information would require constant communication between the 
>ULP and the DDP implementation to relay information about the credits 
>that had been passed to the peer. Such communication would be a 
>performance problem on the backplane. The ULP and not DDP should be 
>responsible for detecting that the peer has overrun its credits. 
>
There are no more interactions than are required when fully provisioning
the buffers. There is an inherent need to a) provide buffers and b)
notify the ULP of completed reads.

An example local interface would have the following capabilities:

-- post buffer and credit to Endpoint

    Number of allowed untagged messages for Endpoint increments.
    Buffer is placed in receive queue for Endpoint (normally)
        or in an associated Shared Buffer Pool / Shared Receive Queue 
        (if the Endpoint is so configured).
        
-- grant credits to Endpoint

    without actually providing any buffers -- increasing the amount
    of underprovisioning.
    
-- post buffer without credit to Endpoint

    To decrease the number of buffers.
    
Only the first method/verb would be used during the processing of
a typical transaction. A typical session would post some buffers,
and if underprovisioning is to be used, some additional credits.
As each completino is processed, a replacement buffer/credit is
provided.

Now the ULP is free to bundle these steps. If it wants to process
three transactions and then post a single replacement with three
buffers and credits. A more promising optimization might be to allow
the replacement buffer and credit to be posted in the same operation
as the reply message.

I am not proposing a mandated procedure on *how* the ULP meters
receives. Merely that it remain part of the loop.

But given that the credit can easily be piggy-backed on re-enabling
the buffer and/or sending the reply, I do not see how this can be
a performance issue.

>What is necessary to protect other connections in a shared buffer pool 
>situation is to deal with the problem of a peer that has tied up 
>excessive numbers of partially filled buffers. The ULP can only see 
>completions, so an attack is possible by sending segments for many 
>messages without completing any message. For instance, in the verbs 
>document, we put an alarm (with threshold settable by the ULP) for 
>excessive incomplete buffers in a receive queue.

An Alarm that requires a ULP response is inherently suspect as a
defense againt a Denial of Service attack.

A static limit also does nothing to prevent an over-eager peer that
always puts the next request on the wire too early. A static limit
is fixed at N, it does not realize that it should be N-m because
there are already m completed messages being processed.

Virtually every ULP protocol seen to data limits the number of
untagged messages that have not been responded to. Expanding the
range of Valid MSN by posting a nrw receive operation (whether
to the specific EP or to its pool) accomplishes this because it
is done *after* the ULP hass finished processing a message.

This sets the valid MSN window to the correct value, and can do so
as part of inherent per-transaction interactions.