Subject: [rddp] MPA issues and next steps

From: "Culley, Paul" <[email-masked]>
Date: Tue, 22 Jul 2003 09:17:12 -0500

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

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 22 Jul 2003 11:22:08 -0500

> check that ULPs were starting MPA correctly (no Active/Active or

In my experience Active/Active startup is most widely deployed in
protocol manuals that have to spend several pages dealing with
the corner cases on the states that are only required by active/active.

Neither the DAT or IT-API provide any support for active/active.

I've already figured out how to deal with it for the equivalent
SCTP startup, but would prefer to simply delete it. With any luck
your request and this observation will be met with thunderous silence,
confirming that nobody has any real interest in active/active startup.

I am curious though, exactly how a passive/passive startup would start.

> key, as well as appropriate interfaces to deal with the private data.

I believe this would be a valuable addition to the protocol. However,
the procedures proposed in section 13 of the most recent draft are
more than adequate.

The key is to allow something *below* the ULP to support transport
neutral stream initiation. I do not believe it is necessary for
the entire algorithm to be implemented in the two adaptation layers.

> document a WG item, then we can argue over the details of this 
I'd be happy to draft these as sections of the applicability draft,
covering both MPA/TCP and SCTP in the same discussion. That would allow
each LLP-specific draft to focus on what the implementers of that
specific adaptation must do.