Re: MPA startup sequence issues (1) and (2)

"Caitlin Bestler" <[email protected]>
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
[email protected] said:
> 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.

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).

>
>   (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.
>

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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.