Subject: RE: [rddp] MPA issue (3): Rejected Connection bit

From: "Carrier, John" <[email-masked]>
Date: Thu, 8 Apr 2004 10:18:48 -0700

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-masked] [mailto:[email-masked]]On Behalf Of
> Caitlin Bestler
> Sent: Thursday, April 08, 2004 12:20 AM
> To: Carrier, John
> Cc: [email-masked]
> 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-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> 

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 9 Apr 2004 03:32:16 -0500 (CDT)

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

---

From: Mike Ko <[email-masked]>
Date: Fri, 9 Apr 2004 15:01:51 -0700

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-masked]
To:     "Carrier, John" <[email-masked]>
cc:     "Caitlin Bestler" <[email-masked]>, [email-masked] 
Subject:        RE: [rddp] MPA issue (3): Rejected Connection bit

> from the TCP stream.  The ULP would then, presumably, terminate the

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.