MPA issues and next steps

As David has covered the workgroup issues around CRCs and Markers I
think it is time to address some other issues.  While we were short on
time to discuss these things in Vienna, I did hear some opinions from
people on what we need to do to complete the MPA "connection setup"
process.

1) MPA will now require a "Startup Key" exchange prior to sending any
FPDUs.

2) In the current draft, the "Startup Key" consists of a fixed ID, CRC
flag, Marker Flag, and Revision.

3) It was proposed to add an "Active/Passive" indication to allow MPA to
check that ULPs were starting MPA correctly (no Active/Active or
Passive/Passive starts).

4) It was proposed to add a "Private Data" field and associated length
field to the key.  This would primarily be used when MPA starts up
directly as TCP enters "established" state.

  4a) The "private data" must be delivered on reception to the ULP,
after which the ULP provides the parameters to enter full operations
(QP, PD, initial buffers etc.), or to terminate the connection.  This
implies an MPA "mode" which can send and wait for the reception of the
key, as well as appropriate interfaces to deal with the private data.

5) We need to show all the connection startup possibilities in the MPA
draft, and discuss rules/issues with each:

  5a) Startup immediately following TCP established with NO private
data;  MPA key exchange, followed by full operation.

  5b) Startup immediately following TCP established with private data;
MPA key/private data exchange, followed by full operation.

  5c) Startup following prior streaming mode data exchanges; quiesce
stream data, MPA key/private data exchange, followed by full operation.

There were some opinions that said that the "Startup Key" and "Private
data" responsibility could be left up to some ULP above the MPA layer.
In this case the draft would only require that these be sent and
received, but not say that MPA was itself responsible.  I don't think we
need to say this directly, but can simply say that an endpoint that is
compliant with MPA must send and receive the key and private data.  We
can leave it to the vendors to describe what parts of the spec are
executed by the hardware/device driver, and what parts are left to other
layers.

I suggest that to clarify the intent, that we provide an -EXAMPLE- ULP
interface, that presumes that all of the MPA functionality is present in
a single layer, similar to the function calls shown in the RDDP
architecture draft.  If, at some point, the WG decides to make a "verbs"
document a WG item, then we can argue over the details of this interface
in there.

Any comments?

Paul R. Culley
HP Senior Fellow
281-514-5543