RE: Whither the RDDP WG

My main concerns in waiting was 1) give everyone a rest and 2) give the
market time to stabilize - constantly "improving" specs can actually
stop deployment.



Jim




> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
Of
> Caitlin Bestler
> Sent: Thursday, October 13, 2005 8:57 AM
> To: [email protected]
> Subject: RE: [rddp] Whither the RDDP WG
> 
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On
> > Behalf Of Jim Pinkerton
> > Sent: Wednesday, October 12, 2005 6:45 PM
> > To: [email protected]; [email protected]
> > Subject: RE: [rddp] Whither the RDDP WG
> >
> >
> > I would suggest that we let the work group remain idle for a
> > year or so, and then re-convene on the next round of
> > innovation. Areas of interest
> > include:
> >
> > - extending the protocol to support atomics
> > - extending the protocol to support concepts of collective
> > operations (aka MPI).
> > - extending the protocol after iSCSI/NFS work is done and we
> > better understand the bottlenecks that they encountered so
> > that we can go for a version 2 of this protocol.
> >
> > One of the things that is worthwhile pointing out is the RDMA
> > Read creates huge opportunities for new innovation
> > (generically fetch&op).
> > Atomics are obvious. I expect other areas will come up as
> > applications begin to better understand this new paradigm.
> >
> 
> And RDMAP/DDP as protocols are very well structured for
> extensibility.  The are more then enough unused opcodes
> and even more unused queue numbers. The model of sending
> an untagged message to a special queue number should
> allow for easy protocol extension.
> 
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp