Re: [rddp] Storage Maintenance (storm) BOF reminder & requests

Black_David@xxxxxxx · 12.03.2009 00:29

David, All,
While I am unfortunately unable to attend the BOF
this week,
I am interested in contributing to
- RDDP MPA: Small startup update for MPI application
support.
preferably through your Option (C), the "virtual"
working group.

    ***
The interoperability of MPA-based RDMA connection
management
is still a concern - for MPI, NFS/RDMA and other apps.
Because MPA has the (theoretically well-known) requirement
that
the first FPDU be sent from the RDMA initiator side,
whereas
InfiniBand has no such requirement, RDMA application
writers
tend to be caught by surprise when an application
that violates
this requirement works on InfiniBand but doesn't on
iWARP.
The so-called "peer-to-peer connection management"
that was
discussed in various flavours on the Linux OpenFabrics
reflector for making RDMA connection management more
uniform
(among transports) and easier to use should be studied
in detail.
The solution should be flexible enough to allow an
optimized
application to avoid unnecessary additional round-trip
delays.
In addition, MPA's "delayed startup sequence"
(a.k.a. delayed
transition to RDMA mode or socket conversion) may
need further
clarification. For instance, the negotiation of connection
parameters such as IRD and ORD should be clarified
for cases
where Private Data is not used in MPA Request/Reply.
(IRD adjustment in RTS state is not mandatory according
 to the RDMAC Verbs, p. 74).

    ***
Besides contributing to draft text, I am interested
in
early testing of the MPA startup update through a
software implementation.
Thanks,
- Fredy
-----------------------------------
Fredy Neeser, Research Staff Member
IBM Zurich Research Laboratory
Saeumerstrasse 4
CH-8803 Rueschlikon, Switzerland

e-Mail: nfd@xxxxxxxxxxxxxx

Phone : +41 (0)44 724 8487
-----------------------------------
This is a reminder that the Storage Maintenance BOF
will

be held in about 2 weeks at the IETF meetings in San Francisco.

Please plan to attend if you're interested:

THURSDAY, March 26, 2009

Continental 1&2              
    TSV            
      storm          
         Storage Maintenance BOF

The BOF description is at:

http://www.ietf.org/mail-archive/web/ips/current/msg02669.html

The initial agenda is here:

http://www.ietf.org/mail-archive/web/ips/current/msg02670.html

I'm going to go upload that initial agenda as the BOF agenda,

and it can be bashed at the meeting.

The primary purpose of this BOF is to answer two questions:

(1) What storage maintenance work (IP Storage, Remote Direct

Data Placement) should be done?

(2) Should an IETF Working Group be formed to undertake that

work?

Everyone gets to weigh in on these decisions, even those who

can't attend the BOF meeting.  Anyone who thinks that there is

work that should be done, and who cannot come to the BOF meeting

should say so on the IPS or RDDP mailing lists (and it'd be a

good idea for those who can come to do this).  As part of the

email, please indicate how you're interested in helping (author

or co-author of specific drafts, promise to review and comment

on specific drafts).

Here's a summary of the initial draft list of work items:

- iSCSI: Combine RFCs into one document, removing unused features.

- iSCSI: Interoperability report on what has been implemented and

interoperates in support of Draft Standard status for iSCSI.

- iSCSI: Add backwards-compatible features to support SAM-4.

- iFCP: The Address Translation mode of iFCP needs to be deprecated.

- RDDP MPA: Small startup update for MPI application support.

- iSER: A few minor updates based on InfiniBand experience.

Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes,

updated ipsec security profile [i.e., IKEv2-based]) is possible if

there's interest.

There are (at least) four possible outcomes:

(A) None of this work needs to be done.

(B) There are some small work items that make sense.  Individual

drafts with a draft shepherd (i.e., David Black) will

suffice.

(C) A working group is needed to undertake more complex work

items and reach consensus on design issues.  The WG can

be "virtual" and operate mostly via the mailing list

until/unless controversial/contentious issues arise.

(D) There is a lot of complex work that is needed, and a WG

that will plan to meet at every IETF meeting should be

formed.

Please note that the IETF "rough consensus" process requires
a

working group in practice to be effective.  This makes outcome

(C) look attractive to me, as:

- I'm coming under increasing pressure to limit travel, and

the next two IETF meetings after San Francisco are not

in the US.

- I'd rather have the "rough consensus" process available and

not need it than need it and not have it available.

Setting an example for how to express interest ...

---------------

I think that the iSCSI single RFC and interoperability report are

good ideas, but I want to see a bunch of people expressing interest

in these, as significant effort is involved.  It might make sense

to do the single iSCSI RFC but put off the interoperability report

(the resulting RFC would remain at Proposed Standard rather than

going to Draft Standard), as I'm not hearing about major iSCSI

interoperability issues.

I think the latter four items (SAM-4 for iSCSI, deprecate iFCP

address translation, MPI fix to MPA and iSER fixes) should all

be done.

I plan to author the iFCP address translation deprecation draft,

and review all other drafts.

I think that a virtual WG should be formed that plans to do its

work primarily via the mailing list.  I believe the SAM-4 work

by itself is complex enough to need a working group - I would

expect design issues to turn up at least there and in determining

whether to remove certain iSCSI features, but I'm cautiously

optimistic that the mailing list is sufficient to work these

issues out (and concerned that travel restrictions are likely to

force use of the mailing list).

-----------------

Ok, who wants to go next?

Thanks,

--David

----------------------------------------------------

David L. Black, Distinguished Engineer

EMC Corporation, 176 South St., Hopkinton, MA  01748

+1 (508) 293-7953             FAX: +1 (508)
293-7786

black_david@xxxxxxx        Mobile: +1 (978) 394-7754

----------------------------------------------------

_______________________________________________

rddp mailing list

rddp@xxxxxxxx

https://www.ietf.org/mailman/listinfo/rddp

_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ips

From:	Black_David@xxxxxxx
To:	<ips@xxxxxxxx>, <rddp@xxxxxxxx>
Cc:	imss@xxxxxxxx, Black_David@xxxxxxx
Date:	12.03.2009 00:29
Subject:	[rddp] Storage Maintenance (storm) BOF reminder & requests
Sent by:	rddp-bounces@xxxxxxxx