Re: MPA issues and next steps

On Tuesday, July 22, 2003, at 09:17 AM, Culley, Paul wrote:

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

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.

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

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.


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