Re: MPA issue (3): Rejected Connection bit

"Talpey, Thomas" <[email protected]>
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.