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

From: "Carrier, John" <[email-masked]>
Date: Wed, 7 Apr 2004 11:08:07 -0700

Okay, so let me take another shot at clarification:
 
The draft shows that MPA is in 'responder mode' while waiting for the MPA Request Frame.  Saying that the connection stays in 'TCP stream mode' after sending the Reject Reply Frame is not a sufficient description of the state change in MPA because it was in 'TCP stream mode' while in 'responder mode'.  
 
So, from a state machine perspective:
* the ULP at the responder puts MPA into 'responder mode' while it waits for the Request Frame from the initiator.  In this state, MPA consumes the TCP data stream.
* after the responding MPA receives an MPA Request Frame from the MPA initiator, it transitions to a 'request received' state.  In this state, the connection is still in TCP stream mode, although MPA is not expecting any other received data from the initiator (should there be an error if it receives any?).  MPA stays in this state until it receives an indication from the ULP to reply to the initiator. 
* if the Request Frame is valid and the ULP accepts the connection, MPA will transition to 'MPA mode' after sending the Reply Frame with the rejected bit set to 0.  In this state, MPA at the responder is bound to DDP and is waiting for the first FPDU from the initiator.  'Full MPA mode', where the responder can send FPDUs, doesn't occur until after the responder receives the first FPDU from the initiator.
* 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.
 
--jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Talpey, Thomas
Sent: Wednesday, April 07, 2004 7:19 AM
To: [email-masked]
Subject: Re: [rddp] MPA issue (3): Rejected Connection bit

At 08:21 PM 3/29/2004, [email-masked] wrote: 
>I suggest to the WG that the right thing to do is include this bit 
>because it produces better behavior in an important error case for 
>cooperative clients where something is misconfigured.  This bit 
>allows the RDDP layers to immediately know that a connection setup 
>has failed and release/reuse any resources committed to it without 
>waiting for a ULP to look at the private data that came back.  It 
>also ties the fact that the connection is closing with the 
>associated private data unambiguously (both can be immediately 
>logged at RDDP level).  Yes, this is optimizing an error case, 
>but it seems to be common enough/of sufficient concern to be 
>worth spending a bit on. 

I agree with this, and would add that by not having the bit, RDDP 
violates layering requirements on TCP regarding the FIN. In order 
to unambiguously indicate "reject" to the RDDP peer, the TCP FIN 
must accompany the returned private data. Otherwise, the 
initiating peer must wait for a subsequent close. Also, with the 
bit, the connection may remain open for further operation in 
streaming mode, if desired. 

Here is some proposed text around the reject bit. 

The Reject bit provides a means for the responding MPA peer to 
reject an incoming RDDP connection. When an incoming connection 
is unacceptable to the responding peer, the Reject bit MUST be 
set in the reply, along with any ULP-specific private data. When 
the Reject bit is true, the connection remains in stream (TCP) mode, 
and may be used and/or subsequently closed by either peer. 

Additional justifications: 

Enhances interoperability by not leaving reject to the upper 
layer. This permits ULP-independent rejection, and does not 
require ULP private data manipulation. 

Simple, non-complicated change to MPA (single bit). 

Does not require the receiver to wait for subsequent event, 
as current proposal does (the FIN). 

Allows receiver to clean up MPA resources immediately 
upon rejection, avoiding resource retention if connection 
not closed. 

Tom.

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 8 Apr 2004 02:19:58 -0500 (CDT)

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