RE: MPA issue (3): Rejected Connection bit

Sounds good to me. Thanks for the clearer rewording.

Only thing to add is that after the last step, the ULP can
choose to return the MPA to Responder mode, or close the
connection, etc as previously discussed.

Tom.

At 02:08 PM 4/7/2004, Carrier, John wrote:
>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.