RE: MPA issue (3): Rejected Connection bit

The handling of the MPA Request Frame was not considered when the iSER 
draft was written.  But since the decision to enter RDMA mode is made 
during the iSCSI login phase in stream mode, if the subsequent MPA Request 
Frame is invalid, it will be treated as an LLP error and presumably the 
MPA layer will be instructed to tear the connection down.

Mike
Sent by:        [email protected]
To:     "Carrier, John" <[email protected]>
cc:     "Caitlin Bestler" <[email protected]>, [email protected] 
Subject:        RE: [rddp] MPA issue (3): Rejected Connection bit



Carrier, John said:
> Hi Caitlin,
>
> Again a clarification: MPA does not send a Reply Frame unless instructed
> to do so by the ULP.  If MPA receives an invalid Request Frame, then it
> indicates the error to the ULP but takes no other action of its own.
>
> My interpretation of what you describe below is that if there is an
> invalid Request Frame, there should be no Reply Frame generated.  In 
that
> case, MPA would transition to what I called the 'inactive' state after 
it
> passes the error to the ULP. The result would be that MPA is decoupled
> from the TCP stream.  The ULP would then, presumably, terminate the
> connection.
>
> right?
>

Yes, with the understanding that the ULP may have instructed MPA in 
advance
to terminate the connection. But the decision to terminate the connection
should indeed belong to the ULP.

Applications using the "connect or using RDMA or bust" APIs currently
found in DAT and IT-API would presumably prefer for the TCP connection
to be terminated rather than being forced to do a round-trip.

Those doing iSER/SDP over iWarp style setup might want their connection
back to allow them to continue in non-RDMA mode (even though it is
more likely that they negotiated use of RDMA in streaming mode, so
a failure to enter RDMA mode would probably still result in terminating
the connection -- who wants to deal with a peer that changes their
mind that quickly?)

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