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

From: "Julian Satran" <[email-masked]>
Date: Sun, 29 Sep 2002 06:14:59 +0300

An ack is just one for 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.

Julo

Caitlin Bestler <[email-masked]>
29/09/02 04:50

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

On 9/29/02, Julian Satran wrote:

>Caitlin,
>
>Implementation might involve some complexity but I am not
>sure that the RNIC must understand the ULP messages. What
>I had in mind is that the local ULP will take care to
>notify the RNIC about transition.
>
>If the stream is "read ahead" then the RNIC might have
>passed some RDMA frames without knowing and some
>additional things might be required (pacing, some
>predefined/empty RDMA frames).
>
>Julo
>

Conventional NICs pass L2 frames to a software stack.
It is then parsed, and buffered until the receiving socket
requests the data. Hence "read ahead" is not an "if", it
is almost a certainty if the next frame arrives before the
ULP has had time to respond.

Pacing / empty frames / etc. are just hacks attempting
to finesse the absence of an ack. They are placing a
real-time constraint on the combination of the non-RDMA IP
stack and the ULP. Almost any such timing constraint will
either artificially slow down connection establishment or
fail on certain OSs under certain conditions (such as heavy
thrashing of applications to from swap disk).

Wouldn't it make more sense to define a solution that does
not require finessing a race condition?

Caitlin Bestler
http://asomi.com/CaitlinBestler/

---

From: Caitlin Bestler <[email-masked]>
Date: Sun, 29 Sep 2002 11:41:31 -0500

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

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
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp