Subject: [rddp] Alignment Commentary

From: [email-masked]
Date: Mon, 13 Jan 2003 20:10:01 -0500

A bit over a week ago, as WG chair, I posed the issue:

> So, I believe the primary issue before the WG is whether to accept:
> 	- The RDDP protocols must allow implementations over
> 		unmodified TCP/IP stacks.
> as a requirement.  If this should be accepted as a requirement,
> then sender alignment cannot be required of all senders (this
> wouldn't rule out negotiating it in some fashion).

Looking back over discussion since then, I've seen a fair amount
of discussion of implications.  I'm going to comment on some of that
discussion, but leave the issue open for at least the rest of this
week for further discussion.

The key implications seem to involve receiver behavior when the
sender is not modified (and in particular winds up sending unaligned
due to factors beyond its control), as Jim Williams asked:

> What is the required performance of an RDMA receiver when
> receiving data from a transmitter using an unmodified TCP/IP stack?

This is somewhat subtle, as I believe the bulk of the answer
is to be found in what I originally wrote after commenting on the
divergence of views on this topic:

> Fortunately, the WG does not need to settle this issue - implementers
> are always free to optimize whatever cases they believe are important.

or in Paul Culley's words:

> Of course all issues surrounding performance are really for the market
> to decide.

So, I would suggest that trying to write MUST or SHOULD requirements
for receiver performance in this scenario is probably not a good idea.
It's also unlikely to succeed, given the clear divergence of views on
this subject - I believe I've seen support for all three possibilities
that Jim listed:

>     1.  Only functional correctness matters, performance is not an issue.
> 
>     2.  Performance must be as good as conventional (non-RDMA) TCP.
>
>     3.  Performance must be significantly better than conventional
>         (non-RDMA) TCP otherwise RDMA should not be used in this case.

Given this, the most appropriate thing for the WG to do may be to ensure
that implementers can make choices as they see fit and that the market has
the opportunity to decide - this would be based on following the following
guidance from Section 6 of RFC 2119 on usage of requirements imperatives
such as MUST, SHOULD, and MAY:

   For example, they must not be used to try to impose a particular
   method on implementors where the method is not required for
   interoperability.

For this specific issue, this guidance could be realized as a WG
approach of avoiding design approaches and decisions that have the
effect of ruling out any of the three alternative views listed above.
I would ask people to consider this approach in further discussion.

I also want to remind people of an important point related to the
following comment that Paul Culley made:

> That said, I can see very interesting scenarios where large numbers
> of slow clients using unmodified stacks is NOT a design point.
> Implementations that perform poorly in this case are perfectly
> acceptable and, if cheaper, preferred.  Most of these scenarios
> involve a machine room or small campus environment, which also
> makes deployment of RDDP reasonable in the near term.

As written, Paul's comment is a reasonable rationale for why
implementations matching view 1 above are important.

I want to caution against moving beyond what Paul wrote to argue
that this class of deployment scenario is the only one worth designing
RDDP protocols for - that sort of approach runs counter the IETF
principle of not designing protocols that are intended solely for
operation on private networks, even though many IETF protocols
are widely deployed on private networks.

No criticism of Paul's remarks is intended - what he wrote is a nice
example of staying on the correct side of this distinction while making
his case for the class of implementation he believes is important.

The alignment issue is still open.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Barron, Dwight" <[email-masked]>
Date: Wed, 15 Jan 2003 10:41:24 -0600

The impact of this form optionality is that every implementor has to implement both options (on and off) and QA four permutations (mine on, your's on; mine on, your's off, etc.) to insure true interoperability. This seems a rather high price to pay today for something that may happen five years hence.

Regards,
Dwight

> -----Original Message-----
> From: Williams, Jim [mailto:[email-masked]]
> Sent: Wednesday, January 15, 2003 9:13 AM
> To: 'Caitlin Bestler'; [email-masked]
> Subject: RE: [rddp] Alignment Commentary
> 
> 
> Caitlin Bestler wrote:
> > 4) Are MPA markers sufficiently complex for
> >    a pure software stack to implement that it is
> >    worth negotiation of a "no-marker" mode?
> >    
> >    IMHO, Markers are truly ugly but ultimately
> >    not that hard to implement. It is not worth
> >    the complexity of supporting multiple modes
> >    and negotiating their use.
> 
> In my mind, the strongest argument for making
> markers optional (assuming, hypothetically, that
> they are supported at all) is that five years
> from now when people realize that they were a
> bad idea and nobody is using them, they can simply
> be opted out.
> 
> If you make them manditory, then if they are
> subsequently discovered to be a mistake,
> it is a much more difficult mistake to correct.

---

From: "Williams, Jim" <[email-masked]>
Date: Wed, 15 Jan 2003 17:04:00 -0500

> From: Barron, Dwight [mailto:[email-masked]]
> Sent: Wednesday, January 15, 2003 11:41 AM
> To: Williams, Jim; Caitlin Bestler; [email-masked]
> The impact of this form optionality is that every implementor 
> has to implement both options (on and off) and QA four 
> permutations (mine on, your's on; mine on, your's off, etc.) 
> to insure true interoperability. This seems a rather high 
> price to pay today for something that may happen five years hence.
> 
> Regards,
> Dwight

Yes, it is true that options have cost.  Of
course if the iSCSI precedent is followed and markers
are optional to implement, then only those that
choose to implement markers pay the cost.

Anyone have feedback on how iSCSI markers are
doing with respect to market acceptance?  Too soon,
I know, but this may be an indicator of how
RDDP markers will fare as there is a
similarity in the cost/benefit (assuming that
RDDP, like iSCSI, does not mandate alignment).
iSCSI markers are potentially more valuable
in that they can be used for error recovery,
whereas RDDP provides no such error recovery
mechanism.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp