Subject: [rddp] MPA startup sequence issues (1) and (2)

From: [email-masked]
Date: Wed, 24 Mar 2004 12:16:44 -0500

This is the first of several emails whose goal is to achieve
mailing list consensus on issues discussed in Seoul.  This
email covers issues (1) and (2), which concern permissible
startup sequences for MPA.  The Seoul minutes say:

  (1) Fast FPDU return (responder need not wait for first pdu). 
  Tentative proposal: leave as-is (responder must wait). 
  No dissension in room.  This is not needed for client/server,
  as the server expects to wait for the client.  Need to take
  proposal to the list. 

  (2) Active/Active startup. Tentative proposal: leave as-is (no 
  support for active/active). No dissension in room.  Note, no 
  known applications require it.  Need to take proposal to the list.

For both of these issues, the rationale for not supporting
the expanded functionality (Fast FPDU return, Active/Active
startup) centers around practical issues for dual-stack
implementations.  draft-culley-mpa-issueresponses-00.txt
contains an extensive discussion of these implementations,
why they're of interest, and the difficulties that these
two features pose to that class of implementation, which
the WG clearly considers to be important.

In other words, this is a "what is reasonable to build
in practice" engineering rationale, as opposed to a "what
is possible in principle" design rationale, which is a good
way to go about making decisions in the IETF.  For the
purpose of starting discussion, since Caitlin Bestler is
the only person I can recall strongly advocating these
two features, I believe that there is rough consensus
not to support them (and hence also not to support them
in the SCTP mapping for consistency).

Not supporting these features means senders MUST NOT
attempt them, and they are an error case at the receiver
if they occur.

For further discussion ...

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: "Caitlin Bestler" <[email-masked]>
Date: Sun, 28 Mar 2004 05:57:36 +0200

>   as the server expects to wait for the client.  Need to take

The additional discussion that clarified the problem being finding
DDP Segments should probably be incorprated. The justification
giving initially was incorrect because it assume the active side
had not chosen an endpoint, when in fact it would typically
have done so. The problem is not in processing these DDP
Segments, its in finding them.

In any event, the class of application that I was concerned with
are "quick fetchers", such as a possible RDMA-HTTP server.
It has since occurred to me that the ULP for such servers
can solve the problem using the current specification by
simply having the side that is passive for TCP be the initiator
for MPA. This class of application will not typically need the
Private Data to select an Endpoint (care in selecting an Endpoint
is a characteristic of a connection that will last a long time,
not a get-in/get-out service).

>   known applications require it.  Need to take proposal to the list.

I'll make the change in the SCTP draft sometime in the next week
or so. I remain ambivalent on the issue. Technically it is not a
justifiable restriction. On the other hand it is not a needed
capability. The consensus seems to favor reducing the test
cases, which strikes me as a valid rationale.

In any event, when the one application that actually comes
along that needs it, we can at least say that we gave them
a chance to object.