Re: [Ips] I-D ACTION:draft-ietf-ips-iser-00.txt

On Sep 15, 2004, at 9:40 PM, Mike Ko wrote:

> Caitlin,
>
>> From section 5.2 of draft-ietf-rddp-rdmap-02.txt on "RDMAP 
>> Interactions
> with the ULP", it states that:
>
> "For RDMA Read Operations, the following are the interactions
> between the RDMAP Layer and the ULP:
>
> *  At the Data Sink:
>
>     *   The ULP passes to the RDMAP Layer the following:
>
>         *   ULP Message Length
>
>         *   Data Source STag
>
>         *   Data Sink STag
>
>         *   Data Source Tagged Offset
>
>         *   Data Sink Tagged Offset"
>
>


Section 5.2 is not written in normative terms.  By contrast section 7
is explicitly normative when it has vertical requirements. Section 5
is clearly intended as a description of the type of interfaces required.
The fact that none of the interface elements are described in detail
is indicative of this intent.

In any event if this were intended to be normative it would be contrary
to the stated policies of the RDDP WG, in that the vertical requirements
are to be specified only as required for interoperability or security.

The intention that the Data Sink STag is opaque can be found in
other sections that *are* explicitly normative:

>        Data Sink Steering Tag: 32 bits.
>
>            The Data Sink Steering Tag identifies the Data Sink's Tagged
>            Buffer. This field MUST be copied, without interpretation,
>            from the RDMA Read Request into the corresponding RDMA Read
>            Response and allows the Data Sink to place the returning
>            data. The STag is associated with the RDMAP Stream through a
>            mechanism that is outside the scope of the RDMAP
>            specification (see Section 10.3 Other Security
>            Considerations).

And
>
>       *  The Data Sink MAY validate that the STag, Tagged Offset, and
>          length of the RDMA Read Response Message are the same as the
>          STag, Tagged Offset, and length included in the corresponding
>          RDMA Read Request Message.

These recognize the fundamental point that the STag used in an
RDMA Write is inherently exposed to both ULP peers, while the
Data Sink STag is explicitly NOT exposed to the Data Source ULP.

So I would interpret the description of the RDMA Read interaction in
section 5.2 to be merely stating that ULP passes in a "Data Sink STag"
which is some form of local-interface-specific handle that identifies
the target buffer. It MAY be the same STag that will be placed on the
wire. But a different STag that references the same buffer MAY be
placed on the wire -- because doing so clearly does not interfere
with interoperability.  The peer ULP does not see the value. The
peer RDMAP layer merely echoes the value.

Without going into implementation details, using an alternate
STag pool for RDMA Reads enables the DDP Layer to validate
that RDMA Read Replies are indeed fully compliant, and not
an attempt to sneak a disguised RDMA Write through without
being detected. It would also enable the ULP to enable a
memory region *only* for RDMA Reads and local operations.
This is particularly useful when the ULP is working through
a transport neutral API.



Note: I have not replied to the IPS list on this topic, because it
is clearly very RDDP specific.








Caitlin Bestler
http://asomi.com/