Re: Storage Maintenance (storm) BOF reminder & requests
Fredy Neeser <[email protected]> Wed, 25 Mar 2009 17:57:35 +0100
| Newsgroups | gmane.ietf.rddp |
|---|---|
| Message-ID | <OFE6A59B51.5C82116C-ONC1257584.00557D3C-C1257584.005D2A1A@ch.ibm.com> |
This is a multipart message in MIME format.
--===============0832860013==
Content-Type: multipart/alternative; boundary="=_alternative 005D29C5C1257584_="
This is a multipart message in MIME format.
--=_alternative 005D29C5C1257584_=
Content-Type: text/plain; charset="US-ASCII"
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: [email protected]
Phone : +41 (0)44 724 8487
-----------------------------------
From:
[email protected]
To:
<[email protected]>, <[email protected]>
Cc:
[email protected], [email protected]
Date:
12.03.2009 00:29
Subject:
[rddp] Storage Maintenance (storm) BOF reminder & requests
Sent by:
[email protected]
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
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rddp
--=_alternative 005D29C5C1257584_=
Content-Type: text/html; charset="US-ASCII"
<br><tt><font size=2>David, All,</font></tt>
<br>
<br><tt><font size=2>While I am unfortunately unable to attend the BOF
this week,</font></tt>
<br><tt><font size=2>I am interested in contributing to</font></tt>
<br>
<br><tt><font size=2>- RDDP MPA: Small startup update for MPI application
support.</font></tt>
<br>
<br><tt><font size=2>preferably through your Option (C), the "virtual"
working group.</font></tt>
<br>
<br><tt><font size=2>
***</font></tt>
<br>
<br><tt><font size=2>The interoperability of MPA-based RDMA connection
management</font></tt>
<br><tt><font size=2>is still a concern - for MPI, NFS/RDMA and other apps.</font></tt>
<br>
<br><tt><font size=2>Because MPA has the (theoretically well-known) requirement
that</font></tt>
<br><tt><font size=2>the first FPDU be sent from the RDMA initiator side,
whereas</font></tt>
<br><tt><font size=2>InfiniBand has no such requirement, RDMA application
writers</font></tt>
<br><tt><font size=2>tend to be caught by surprise when an application
that violates</font></tt>
<br><tt><font size=2>this requirement works on InfiniBand but doesn't on
iWARP.</font></tt>
<br>
<br><tt><font size=2>The so-called "peer-to-peer connection management"
that was</font></tt>
<br><tt><font size=2>discussed in various flavours on the Linux OpenFabrics</font></tt>
<br><tt><font size=2>reflector for making RDMA connection management more
uniform</font></tt>
<br><tt><font size=2>(among transports) and easier to use should be studied
in detail.</font></tt>
<br><tt><font size=2>The solution should be flexible enough to allow an
optimized</font></tt>
<br><tt><font size=2>application to avoid unnecessary additional round-trip
delays.</font></tt>
<br>
<br><tt><font size=2>In addition, MPA's "delayed startup sequence"
(a.k.a. delayed</font></tt>
<br><tt><font size=2>transition to RDMA mode or socket conversion) may
need further</font></tt>
<br><tt><font size=2>clarification. For instance, the negotiation of connection</font></tt>
<br><tt><font size=2>parameters such as IRD and ORD should be clarified
for cases</font></tt>
<br><tt><font size=2>where Private Data is not used in MPA Request/Reply.</font></tt>
<br><tt><font size=2>(IRD adjustment in RTS state is not mandatory according</font></tt>
<br><tt><font size=2> to the RDMAC Verbs, p. 74).</font></tt>
<br>
<br><tt><font size=2>
***</font></tt>
<br>
<br><tt><font size=2>Besides contributing to draft text, I am interested
in</font></tt>
<br><tt><font size=2>early testing of the MPA startup update through a</font></tt>
<br><tt><font size=2>software implementation.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>- Fredy</font></tt>
<br>
<br><tt><font size=2>-----------------------------------</font></tt>
<br><tt><font size=2>Fredy Neeser, Research Staff Member</font></tt>
<br><tt><font size=2>IBM Zurich Research Laboratory</font></tt>
<br><tt><font size=2>Saeumerstrasse 4</font></tt>
<br><tt><font size=2>CH-8803 Rueschlikon, Switzerland<br>
e-Mail: [email protected]<br>
Phone : +41 (0)44 724 8487</font></tt>
<br><tt><font size=2>-----------------------------------</font></tt>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">[email protected]</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif"><[email protected]>, <[email protected]></font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">[email protected], [email protected]</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">12.03.2009 00:29</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">[rddp] Storage Maintenance (storm) BOF
reminder & requests</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Sent by:</font>
<td><font size=1 face="sans-serif">[email protected]</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>This is a reminder that the Storage Maintenance BOF
will<br>
be held in about 2 weeks at the IETF meetings in San Francisco.<br>
Please plan to attend if you're interested:<br>
<br>
THURSDAY, March 26, 2009<br>
Continental 1&2
TSV
storm
Storage Maintenance BOF<br>
<br>
The BOF description is at:<br>
</font></tt><a href="http://www.ietf.org/mail-archive/web/ips/current/msg02669.html"><tt><font size=2>http://www.ietf.org/mail-archive/web/ips/current/msg02669.html</font></tt></a><tt><font size=2><br>
<br>
The initial agenda is here:<br>
</font></tt><a href="http://www.ietf.org/mail-archive/web/ips/current/msg02670.html"><tt><font size=2>http://www.ietf.org/mail-archive/web/ips/current/msg02670.html</font></tt></a><tt><font size=2><br>
<br>
I'm going to go upload that initial agenda as the BOF agenda,<br>
and it can be bashed at the meeting.<br>
<br>
The primary purpose of this BOF is to answer two questions:<br>
(1) What storage maintenance work (IP Storage, Remote Direct<br>
Data Placement) should be done?<br>
(2) Should an IETF Working Group be formed to undertake that<br>
work?<br>
<br>
Everyone gets to weigh in on these decisions, even those who<br>
can't attend the BOF meeting. Anyone who thinks that there is<br>
work that should be done, and who cannot come to the BOF meeting<br>
should say so on the IPS or RDDP mailing lists (and it'd be a<br>
good idea for those who can come to do this). As part of the<br>
email, please indicate how you're interested in helping (author<br>
or co-author of specific drafts, promise to review and comment<br>
on specific drafts).<br>
<br>
Here's a summary of the initial draft list of work items:<br>
- iSCSI: Combine RFCs into one document, removing unused features.<br>
- iSCSI: Interoperability report on what has been implemented and<br>
interoperates in support of Draft Standard status for iSCSI.<br>
- iSCSI: Add backwards-compatible features to support SAM-4.<br>
- iFCP: The Address Translation mode of iFCP needs to be deprecated.<br>
- RDDP MPA: Small startup update for MPI application support.<br>
- iSER: A few minor updates based on InfiniBand experience.<br>
<br>
Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes,<br>
updated ipsec security profile [i.e., IKEv2-based]) is possible if<br>
there's interest.<br>
<br>
There are (at least) four possible outcomes:<br>
(A) None of this work needs to be done.<br>
(B) There are some small work items that make sense. Individual<br>
drafts with a draft shepherd (i.e., David Black) will<br>
suffice.<br>
(C) A working group is needed to undertake more complex work<br>
items and reach consensus on design issues. The WG can<br>
be "virtual" and operate mostly via the mailing list<br>
until/unless controversial/contentious issues arise.<br>
(D) There is a lot of complex work that is needed, and a WG<br>
that will plan to meet at every IETF meeting should be<br>
formed.<br>
<br>
Please note that the IETF "rough consensus" process requires
a<br>
working group in practice to be effective. This makes outcome<br>
(C) look attractive to me, as:<br>
- I'm coming under increasing pressure to limit travel, and<br>
the next two IETF meetings after San Francisco are not<br>
in the US.<br>
- I'd rather have the "rough consensus" process available and<br>
not need it than need it and not have it available.<br>
<br>
Setting an example for how to express interest ...<br>
<br>
---------------<br>
I think that the iSCSI single RFC and interoperability report are<br>
good ideas, but I want to see a bunch of people expressing interest<br>
in these, as significant effort is involved. It might make sense<br>
to do the single iSCSI RFC but put off the interoperability report<br>
(the resulting RFC would remain at Proposed Standard rather than<br>
going to Draft Standard), as I'm not hearing about major iSCSI<br>
interoperability issues.<br>
<br>
I think the latter four items (SAM-4 for iSCSI, deprecate iFCP<br>
address translation, MPI fix to MPA and iSER fixes) should all<br>
be done.<br>
<br>
I plan to author the iFCP address translation deprecation draft,<br>
and review all other drafts.<br>
<br>
I think that a virtual WG should be formed that plans to do its<br>
work primarily via the mailing list. I believe the SAM-4 work<br>
by itself is complex enough to need a working group - I would<br>
expect design issues to turn up at least there and in determining<br>
whether to remove certain iSCSI features, but I'm cautiously<br>
optimistic that the mailing list is sufficient to work these<br>
issues out (and concerned that travel restrictions are likely to<br>
force use of the mailing list).<br>
<br>
-----------------<br>
<br>
Ok, who wants to go next?<br>
<br>
Thanks,<br>
--David<br>
----------------------------------------------------<br>
David L. Black, Distinguished Engineer<br>
EMC Corporation, 176 South St., Hopkinton, MA 01748<br>
+1 (508) 293-7953 FAX: +1 (508)
293-7786<br>
[email protected] Mobile: +1 (978) 394-7754<br>
----------------------------------------------------<br>
_______________________________________________<br>
rddp mailing list<br>
[email protected]<br>
</font></tt><a href=https://www.ietf.org/mailman/listinfo/rddp><tt><font size=2>https://www.ietf.org/mailman/listinfo/rddp</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>
--=_alternative 005D29C5C1257584_=--
--===============0832860013==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
rddp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rddp
--===============0832860013==--