Subject: [Tsvwg] RE: [rdma] Re: RDMA over IP Requirements draft

From: [email-masked]
Date: Sat, 18 May 2002 15:33:54 -0400

> While I agree that DDP should treat payloads as opaque objects,
applications
> wishing distributed processing of data demands structures be defined and
> converted.  There has been a considerable amount of consolidation in this
> area with regard to interface structure definitions.  As this relates to
DDP
> or ROI, providing a means to define or imply these definitions is a minor
> effort but would help minimize hardware needed.
> 
> This could relate to the use of PPI within SCTP-DDP, as example.
> This can be expanded upon by the ULP and perhaps even enhanced by hardware
> conversion.  Either way, this is intended as an 'on-the-fly' process.

Parsing Doug's posts is often difficult, but I think what he's asking
for in the requirements draft is that DDP and RDMA preserve any
transport-specific means used by ULPs to identify payloads.  For
SCTP, one of the implications would then be that PPI functionality
needs to be made available to the ULP (i.e., if DDP and/or RDMA were
to use the SCTP PPI for their own purposes, they would need to provide
a replacement usable by the ULP).  If that's the case, it seems like
a reasonable thing to add, IMHO.

The implementation architecture that appears to motivate this envisions
a payload-aware programmable byte-swapper in the transfer pipe between
DDP/RDMA and memory and using the PPI as part of telling the byte-swapper
what to do, but significant additional state would have to be configured
by some other means.  Current practice seems to be to use the PPI to
identify the ULP, as opposed to anything finer grain (i.e., which ULP
data structure is in the payload) - see the PPI registry towards the end
of:

	http://www.iana.org/assignments/sctp-parameters

That's enough to make the envisioned byte-swapper possible, but it
will require it to look at the payload (to figure out which routine/
method is being invoked/responded to) in order to determine how to
byte-swap it.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

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

---

From: "Douglas Otis" <[email-masked]>
Date: Sun, 19 May 2002 14:34:59 -0700

David,

There are two points being made where it would appear you agree with
identifying payloads.  This identification is needed to imply interface
definitions.  The other point (less important to RDMA, but useful for DDP)
would be for request structures to comply to a BNF IDL.  At the minimum,
identifying the payloads would acknowledge when such compliance can be
expected.

ONC-XDR and DCE-IDL are a progression of this effort.  RPC to IIOP bridges
into CORBA standards also exist.  Although designed for a procedural
language, DCE is suitable for hardware implementation as there is no
inherited or dynamic interface, uses a flat namespace, supports a full range
of variable types including object oriented.   Complex and extensible
service protocols already support a large interface definition repertoire
and some support dynamic definitions.  Excluding dynamic definitions,
however, should be an option to avoid security risk and problematic hardware
implementation.

Ported applications depend on this interface service.  It would be useful if
the same hardware could be utilized in presenting or parsing RDMA requests.
RDMA is but one of many protocols that could benefit from DDP.  As this
effort is to consolidate hardware, adding this additional goal to ROI
requirements would provide a substantial benefit.  The impact as a
requirement may be none but would be valuable none the less.  Once the
payloads are identified, implying interface definitions can be done through
an extensible convention.

 -Doug

On May 18, 2002 12:34 PM David Black ([email-masked]) wrote:
> > applications wishing distributed processing of data demands
> > structures be defined and converted.  There has been a
> > considerable amount of consolidation in this area with regard
> > to interface structure definitions.  As this relates to DDP or
> > ROI, providing a means to define or imply these definitions is
> > a minor effort but would help minimize hardware needed.
> >
> > This could relate to the use of PPI within SCTP-DDP, as
> > example. This can be expanded upon by the ULP and perhaps even
> > enhanced by hardware conversion.  Either way, this is intended
> > as an 'on-the-fly' process.
>
> Parsing Doug's posts is often difficult, but I think what he's
> asking for in the requirements draft is that DDP and RDMA preserve
> any transport-specific means used by ULPs to identify payloads.
> For SCTP, one of the implications would then be that PPI
> functionality needs to be made available to the ULP (i.e., if DDP
> and/or RDMA were to use the SCTP PPI for their own purposes, they
> would need to provide a replacement usable by the ULP).  If that's
> the case, it seems like a reasonable thing to add, IMHO.
>
> The implementation architecture that appears to motivate this
> envisions a payload-aware programmable byte-swapper in the
> transfer pipe between DDP/RDMA and memory and using the PPI as
> part of telling the byte-swapper what to do, but significant
> additional state would have to be configured by some other means.
> Current practice seems to be to use the PPI to identify the ULP,
> as opposed to anything finer grain (i.e., which ULP data structure
> is in the payload) - see the PPI registry towards the end of:
> will require it to look at the payload (to figure out which
> routine/method is being invoked/responded to) in order to
> determine how to byte-swap it.
>
> Thanks,
> --David