Subject: Re: [rddp] Review comment on DDP untagged buffer model

From: John Hufferd <[email-masked]>
Date: Fri, 11 Jul 2003 00:14:24 -0700

I completely agree with Mallikarjun.  There are straight forward 
techniques to permit the LLP to notice that the buffer is not yet 
available, and drop the buffer, thus permitting  exploitation  of the 
basic retry capability of the LLP. 

I am not saying that it should be required but only that it should be 
permitted, as long as it is transparent to the ULP.

When ever there is a buffer replenishment process from a pool of buffers, 
there is the possibility that because of some hiccup in the system 
(perhaps a higher priority task in the OS being dispatch to handle some 
error recovery process), the replenishment process may not be able to 
replenish the pool in time.  As a result you would have to way over 
compensate by adding and undefined number of buffers, just in case 
something uncontrollable happens.  It is better  to have an RNIC that can 
tolerate a temporary shortage.

Therefore, I agree with Mallikarjun and feel we should NOT mandate that 
the link be dropped if the required buffer is missing.  It should be 
clearly specified that the RNIC could act that way, but it should not be a 
hard requirement that the RNIC must operate in that manner.  In fact if an 
RNIC vendor offers such a retry capability, there may be a number of 
System vendors that would like to use that  RNICs so that the 
applications, which run on their systems, will not be needlessly 
terminated when high priority system processes are invoked.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: [email-masked]

"Mallikarjun C." <[email-masked]>
Sent by: [email-masked]
07/10/2003 07:45 PM

        To:     <[email-masked]>
        cc: 
        Subject:        [rddp] Review comment on DDP untagged buffer model

I  have a comment on the DDP untagged buffer model
of the current DDP spec.

The DDP spec implies that the DDP Stream is to be
dropped by implementations when there is no receive
buffer to place an inbound untagged message.  This
is mandating a specific type of implementation, and IMHO,
is needless.  The DDP spec should instead allow for
implementation flexibility in this area.  Those RNICs
that can gracefully deal with lack of receive buffers
via LLP means (such as TCP retransmit) should be
allowed as well.  I can agree with the authors' original intent
that ULP-level flow control and/or adequate buffer provisioning
must be done to avoid needless retransmits, but mandating
a connection drop on the first instance of hitting a (most
likely a very transient) no-buffer window is severe.

I believe the DDP spec can allow this RNIC implementation
flexibility with minimal text changes.  My review uncovered
only two areas of text that mandated the connection drop
requirement.

section 3.2 (Protocol Overview),
    " Note, however, that
        the ULP needs to address flow control issues because if a DDP
        Message arrives for an Untagged Buffer without an associated
        receive ULP buffer, the DDP Message is dropped, the DDP Stream
        is disabled for reception, and an error is reported to the ULP
        at the Data Sink."

and section 9.1  (Errors detected at the Data Sink).
    "   2.  The QN and MSN have an associated buffer that allows Placement
       of the payload."

My suggestion is to change the text along the following lines:
Section 3.2 to:
    " Note, however, that the ULP needs to address flow control issues."
and section 9.1 to:
    " 2. The QN and MSN have an associated buffer that allows Placement of 
the payload. DDP implementations
MAY optionally consider lack of an associated buffer to be not an error, 
but such implementations MUST ensure
that the DDP Segment is eventually recovered using LLP means in a 
ULP-transparent way."
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
[email-masked]

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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 11 Jul 2003 07:29:34 -0500

> basic retry capability of the LLP. 

On that specific point, I'll agree with you.

An incoming packet that lacks a target buffer, but was still an
enabled receive, MAY be dropped to allow retransmits.
This would conceptually be a feedback from the "placement"
interface from the LLP, the DDP would kickback "sorrry, not
now". If placement could not be done, completion cannot follow.
The LLP would either have to buffer on its own, or drop the
packet and rely on the remote peer to retransmit it.

However, there should be some caution that this SHOULD NOT be
used deliberately as some form of additional flow control.
That is the receiving ULP SHOULD strive to always have an adequate
buffer capacity for authorized untagged messages.

Further, unauthorized untagged messages SHOULD be detected and
not only dropped, but result in termination of the DDP stream.

We have to be cautious about use of drops on the receiving end
being used as a recovery technique. The logical next step is for
a receive to decide that tagged buffers don't *really* need to
kept in memory, they can be swapped out. When a tagged message
arrives we'll just drop it and then start the swap-in process.
The other side will recover eventually, and meanwhile I can advertise
more buffers than I really own.