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

From: "Douglas Otis" <[email-masked]>
Date: Tue, 21 May 2002 11:52:42 -0700

David,

The goal of DDP was to minimize memory operations.  String based data
overcomes CPU architectural differences at the expense of requiring the
equivalence of a memory copy by the CPU for conversion.  Just as DDP places
data on the fly, IDL protocols convert binary data on the fly.  A
recommendation provides consolidation on an IDL and thereby hardware.
Whether it would be appropriate for any particular protocol is not relevant.
Such a consolidation does not "disadvantage" existing protocols that offer
no IDL.  Those protocols require unique hardware in any case.  IDL would not
be a barrier in the use of DDP, however payload identification is important
to ensure IDL hardware is possible.

  -Doug

On May 21, 2002 10:44 AM David Black ([email-masked]) wrote:
>
> [... grabbing a couple of relevant snippets ...]
>
> > For RDMA, the only aspect where this would apply is with respect to
> > 'request' structures.
>
> > Advantaging existing IDL protocols with DDP seems an optimal means to
> > establish a solid yet versatile foundation.
> >
> > It seems we are in nearly total agreement with the exception
> > of actually making a recommendation. ; )
>
> Not exactly.  I see such a recommendation adding essentially no
> value to the design of RDMA 'request' structures and hence would
> omit the recommendation for this specific case.
>
> For DDP in general, a recommendation "advantaging" protocols based
> on an IDL implies "disadvantaging" important existing protocols
> that are not designed in that fashion.  I continue to believe that
> such a recommendation is a bad idea because it will be read as a
> limit on the intended applicability of DDP to existing protocols,
> and hence is unlikely to establish the desired "versatile foundation."
> For example, IMHO, Doug's desire to redesign iSCSI to use an IDL
> is an example of the sort of barrier that should not be placed
> between existing protocols and usage of DDP.
>
> 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: Tue, 21 May 2002 12:33:47 -0700

David,

Obviously, without arriving at consensus, generalized hardware would not be
possible.  Saying some protocols may not utilize a recommendation makes it
not appropriate?  For hardware implementation, I would not expect a
religious war between DCE and IIOP.  While DCE is more constricting, these
constrictions are beneficial with respect to hardware and there are bridges
between these environments.  "Nothing ventured, nothing gained."

 -Doug

On May 21, 2002 12:06 PM David Black ([email-masked]) wrote:
>
> > A recommendation provides consolidation on an IDL and thereby hardware.
>
> I hope Doug mistyped "an IDL" because picking a particular IDL as
> preferred for DDP is as bad an idea as disfavoring protocols that
> weren't designed with an IDL.  That'll set off a quasi-religious
> war among the multiple IDL possibilities that is not necessary and
> does not belong in this forum.  DDP should not be used as a wedge
> to try to force IDL consolidation for the simple reason that it won't
> be brought about in that fashion and shouldn't be attempted.
>
> That definitely reinforces my conclusion to omit any IDL
> recommendation - things that are not appropriate for general use
> should not be in a protocol standard intended for general use -
> "if in doubt, leave it out".
>
> Thanks,
> --David