RE: MPA issue (3): Rejected Connection bit

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?

--jc

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Caitlin Bestler
> Sent: Thursday, April 08, 2004 12:20 AM
> To: Carrier, John
> Cc: [email protected]
> Subject: RE: [rddp] MPA issue (3): Rejected Connection bit
> 
> 
> Carrier, John said:
> 
> > * if the Request Frame is invalid or if the ULP rejects the 
> connection,
> > MPA will transition to an 'inactive' state after sending 
> the Reply Frame
> > with the rejected bit set to 1.  In this state, the TCP 
> connection is
> > open, but MPA is no longer consuming any of the TCP data 
> stream; instead
> > any received data goes directly to the ULP.
> >
> 
> The two reject cases should be distinquished.
> 
> If the Request Frame is invalid the request is being rejected by
> the MPA layer, not by the ULP. There is no Private Data available
> for a response.
> 
> If it was rejected by the ULP, there will be Private Data supplied
> in accordance with the specific protocol. Providing a zero length
> Private Data may have specific meaning under that protocol.
> 
> Generally, if the Request Frame itself is invalid the most likely
> cause is a misdirected connect request by a non-RDMA client.
> Such a client will not be able to parse the Reply Frame anyway
> (and given that it cannot format a Request Frame there is little
> reason to believe that it will).
> 
> In that case I believe the correct respsonse to an invalid request
> frame would be to simply terminate the connection.
> 
> This means that invalid MPA Request Frames will be lumped with
> other "network related" errors from the initiating ULPs perspective.
> In my opinion this is a better grouping than lumping it with a
> peer reject, particularly if it forces the ULP to specify a non-zero
> lenght "nothing" message just to prove it was the ULP that had
> indeed said nothing.
> 
> If someone can suggest a reason why this error is of particular
> signifigance to the source ULP then I could see having a distinct
> error bit. But my suspicion is that this error will seldom be seen
> between actual RDMA peers, and more often be the result of
> a misdirected non-RDMA client.
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>