Re: startup behavior of MPA

On Oct 2, 2004, at 1:47 AM, Barry Reinhold wrote:

> When an MPA implementation sends a startup request frame and receives a
> FPDU back, it is not allowed to interpret/process the FPDU. However, 
> the
> spec does not appear to address the condition after reception of the
> FPDU. One can consider this to be an error and have the connection
> terminated. However, it is not clear that this has to be the situation.
>
> The question is, is it a "MUST" that the connection be terminated on
> reception of a FPDU before a startup reply frame?
>
>

The respondent side MUST NOT send the first FPDU until after it
has received the first FPDU itself, which the initiating side MUST
NOT send until after it receives the startup reply.

So reception of an FPDU before a startup reply frame indicates that
the other side has violated a MUST.  As with any other protocol
violation by the peer it MAY choose to terminate the connection,
and SHOULD do so if the violation could in any way be used to
compromise security.

But it is not obligated to do so.  In particular, it does not have
to take extra steps to insure that it notices this condition.  An
MPA implementation that processes TCP segments in order,
for example, would not notice that the FPDU had been received
before the startup reply frame.

An MPA implementation that processed TCP segments as they
arrived would not know whether the TCP segment was part of
the MPA REP message or part of an FPDU, and therefore
could easily be incapable of submitting it to MPA processing.
That is why the peer was required not to send it.

Also remember that this is an MPA requirement, not an RDDP
requirement.  There is no restriction on first transmit under the
SCTP mapping.