RE: MPA issue (3): Rejected Connection bit

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 protected] [mailto:[email protected]]On Behalf Of Talpey, Thomas
Sent: Wednesday, April 07, 2004 7:19 AM
To: [email protected]
Subject: Re: [rddp] MPA issue (3): Rejected Connection bit



At 08:21 PM 3/29/2004, [email protected] 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.