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

From: [email-masked]
Date: Mon, 20 May 2002 17:19:53 -0400

Doug,

> I have never seen an interface definition encompass transport headers.

That's the point -- if a protocol's headers are designed in a
fashion similar to the way transport headers are designed, the result
won't look like it was generated from an IDL specification.

> Your statement that an IDL consideration should not impact RDMA 
> would seem to
> remove a potential barrier.  Adding this feature as a recommended
> consideration within the design process of request structures seems
> innocuous.  I wonder what your concern is.

XDR is the obvious candidate for an IDL-driven data representation, but
XDR prohibits 8 and 16 bit fields.  There seems to be no point to
such a prohibition in RDMA protocol design.  As long as "IDL consideration"
is read broadly enough to not exclude 8 and 16 bit fields from RDMA
data structures, I suppose I don't have a problem, but I wonder what
the value of including something read that broadly would be; it doesn't
seem to add anything to the sort of design practices that will likely
be followed in laying out data structures anyhow.

> Would you consider a separate requirements document for DDP?
> Within this draft, an IDL recommendation
> would not be out-of-line and may find consensus.

I'm sceptical.  I don't think the IDL recommendation was intended
to apply to the DDP structures themselves, as the structures in Doug's
SCTP-DDP draft don't seem to follow that recommendation (and if those
are "transport headers", one could plausibly argue that the RDMA
structures are "transport headers").  Applying an IDL recommendation
to ULPs that use DDP would in effect exclude ULPs that weren't designed
by using an IDL, and there are a lot of such protocols.  That seems
overly constrained to the point of unwarranted - for example, it would
recommend against any use of DDP with iSCSI or http, even over SCTP -
I don't think that's a good idea.

The reason the second ("I'm sceptical") paragraph differs from the
first paragraph in this message is that an IDL's data representation
format shows up dramatically when variable-length data is involved.
I'm assuming that RDMA headers will be fixed length (and hence the
impact of doing something XDR-like is fairly limited), whereas ULPs
in general (e.g. both iSCSI and http) have variable length components
that aren't laid out in the fashion that an IDL-driven design would use.

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: Mon, 20 May 2002 15:54:54 -0700

David,

The consideration was with respect to structures carried within DDP.  This
consideration would not apply to DDP itself.  I admit the context field
within SCTP-DDP was styled after the SCTP header rather than BNF.  But
again, this aspect should not apply to any IDL recommendation.  The
underlying DDP structures will be consistent without any concern as how ULPs
utilize this capability.  For RDMA, the only aspect where this would apply
is  with respect to 'request' structures.

I see this as only a recommendation and not a mandate.  It could apply to
SCSI and RDMA requests.  Both of these protocols will evolve and are
advantaged by versatile hardware able to adapt to new formats.  This
hardware will exist to handle other IDL based protocols.  If iSCSI were
applied to SCTP-DDP, a large amount of the iSCSI format is affected by
functional overlap.  The SCTP multi-homing and Data Chunk already handle
many aspects found within iSCSI as do fields within DDP.  There of course
would be less desire within TCP/IP to follow this recommendation.

Again, this was to include a recommendation where the use of an IDL be
considered within the design of these structures carried within the DDP
capable transport.  If a string based protocol wishes to use DDP, then
encapsulation afforded should represent a small overhead compared to parsing
strings.  The area where I see this having the greatest impact would be with
binary structure exchanges on high speed links.  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. ; )

 -Doug

On May 20, 2002, 2:20 PM David Black ([email-masked]) wrote:
> fashion similar to the way transport headers are designed, the
> result won't look like it was generated from an IDL specification.
>
> > would seem to remove a potential barrier.  Adding this feature as
> > a recommended consideration within the design process of request
> > structures seems innocuous.  I wonder what your concern is.
>
> XDR is the obvious candidate for an IDL-driven data representation,
> but XDR prohibits 8 and 16 bit fields.  There seems to be no point
> to such a prohibition in RDMA protocol design.  As long as "IDL
> consideration" is read broadly enough to not exclude 8 and 16 bit
> fields from RDMA data structures, I suppose I don't have a problem,
> but I wonder what the value of including something read that broadly
> would be; it doesn't seem to add anything to the sort of design
> practices that will likely be followed in laying out data structures
> anyhow.
>
> to apply to the DDP structures themselves, as the structures in
> Doug's SCTP-DDP draft don't seem to follow that recommendation (and
> if those are "transport headers", one could plausibly argue that the
> RDMA structures are "transport headers").  Applying an IDL
> recommendation to ULPs that use DDP would in effect exclude ULPs
> that weren't designed by using an IDL, and there are a lot of such
> protocols.  That seems overly constrained to the point of
> unwarranted - for example, it would recommend against any use of DDP
> with iSCSI or http, even over SCTP - I don't think that's a good
> idea.
>
> in general (e.g. both iSCSI and http) have variable length
> components that aren't laid out in the fashion that an IDL-driven
> design would use.
>
> Thanks,
> --David