Subject: RE: [rddp] Stream Initiation (8.1)

From: "Garcia, Dave" <[email-masked]>
Date: Tue, 24 Sep 2002 16:45:29 -0700

There is no requirement that RDMAP/DDP/MPA start immediately
after TCP starts. It could, if both sides agreed to do that.
The text states "The ULP is responsible for transitioning the
LLP stream into RDMA enabled mode". It would have been more
clear to add the sentence "This transition can occur immediately
after the connection is established or at any mutually agreed
upon point afterwards." This should answer the other problems 
you mention.

Dave Garcia
HP

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]]
Sent: Tuesday, September 24, 2002 4:07 PM
To: [email-masked]
Subject: [rddp] Stream Inititation (8.1)

In section 8.1 the RDMAP draft specifies that the ULP peers
must agree on the send credits, rdma read credits, permitted
modes and configure the RDMAP/DDP layers as agreed before
RDMA mode is enabled.

This matches prior proposals.

It also states that that "RDMAP Stream initialization occurs
after the LLP Stream has been created (e.g. for DDP/MPA over
TCP the first TCP Segment after the SYN, SYN/ACK exchange)"

Wouldn't that make it impossible to negotiate connection
specific resource levels? There would still be protocol
specific, but negotiating connection specific would require
communicating *before* the connection was established.

Establishing a pair of connections between two NATted nodes
without protocol specific support in the firewall is
difficult to impossible.

In order to be truly transparent to all NAT boxes, doesn't
RDMAP have to be negotiated in a manner that allows it to
function over a single LLP connection without resorting to
UDP exchanges or multiple connections?

Is there a specific reason for not allowing a single TCP
segment exchange to establish stream-specific parameters?

This is less of a concern for SCTP, because the ULP could
easily use a different stream to negotiate RDMAP parameters
on the other streams.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
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: "Julian Satran" <[email-masked]>
Date: Mon, 30 Sep 2002 10:54:40 +0300

Caitlin,

The bulk login mechanism that iSCSI uses DOES NOT require interpretation 
by any NIC.
It practically defers the state transition to the end of a negotiation 
phase - and  is deterministic (as many other pacing mechanisms).

I do think that you need the recognition of a RDMA frame as your and 
Paul's message seem to indicate.

Switching is negotiated at the ULP level only and communicated locally at 
the two ends.

It will work with any request/response asymmetric ULP.

It may require two independent negotiation phases for a completely 
symmetric scheme.

Julo

Caitlin Bestler <[email-masked]>
29/09/02 18:41

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc: 
        Subject:        RE: [rddp] Stream Inititation (8.1)

On 9/29/02, Julian Satran wrote:

>An ack is just one form of pacing in this case and it will
>require the sender to stop sending until receiving the ack
>the activating the rdma at the send side. An equivalent
>effect can be achieved by a "bulk ack" (as in the login
>phase of iSCSI) in which the RDMA could start just after
>the login.
>

But an ack is a reliable form of pacing, whether it is
explicit or implicit (as in the first actual RDMA message
serves as an implicit ack to enable the reverse mode send).

Pacing which is not message dependent is timing dependent.
Such protocols can indeed be made to work. However, as
currently drafted we are requiring ULP peers, working
through non-RDMAP/DDP stacks, to negotiate concurrent entry
into RDMA mode without giving them the ability to ack.

These are application layer peers, outside the scope of our
specifications, working through software that is outside of
our scope. How can we expect them to reliably impose hard
time based synchronization?

iSCSI login, by contrast, has defined messages and state
transitions which could be interpreted and acted upon
directly by the NIC and/or kernel level software. Our ULP
specific negotiations CANNOT be acted upon at any layer
below the ULP itself.

Caitlin Bestler