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

From: [email-masked]
Date: Fri, 27 Sep 2002 13:33:04 -0600

Caitlin,

The method for the transition should be left up to the ULP. 

One method is:

Both sides negotiate agreement to use RDMAP.
When the ULP is ready to start transmitting RDMAP (as defined by the ULP's negotiation method), the ULP transmits a switch PDU which indicates it is the last non-RDMA PDU.
When the other ULP receives the switch PDU, it turns on RDMAP for the receive stream.

There is no need for the transmitter to wait for TCP acks to coordinate this.

Regards,
Pat

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]]
Sent: Thursday, September 26, 2002 2:04 PM
To: THALER,PAT (A-Roseville,ex1); [email-masked]
Subject: RE: [rddp] Stream Inititation (8.1)

On 9/26/02, THALER,PAT (A-Roseville,ex1) wrote:

>Caitlin,
>
>The statement is accurate but perhaps misleading taken
>alone. "After" was not meant to mean "immediately after".
>It can be "sometime after". The next sentences should
>clarify that meaning: "The ULP is responsible for
>transitioning the LLP Stream into RDMA enabled mode. Once
>in RDMA enabled mode, an implementation MUST send only
>RDMA Messages across the transport Stream until the RDMAP
>Stream is torn down."  
>
>The intent is that you can bring up a connection with
>RDMAP off, negotiate over the connection and then
>transition to RDMAP on.
>
>Pat
>

What should be specified as to any anacked portion of
outbound stream at the time of enabling RMDA?

a) It's not allowed. At the time of transition all
previously sent bytes must be fully acked. The next
TCP segment received is assumed to be in RDMA mode.

b) The transition is understood to take place after all
previously transmitted bytes. Co-ordinating this with the
peer is the ULP's responsibility. The first segment after n
bytes (as specified by the local ULP) will be assumed to be
in RDMA mode.

I would assume option A, but that also should be specified.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 27 Sep 2002 14:59:27 -0500

On 9/27/02, [email-masked] wrote:

>Both sides negotiate agreement to use RDMAP. When the ULP
>is ready to start transmitting RDMAP (as defined by the
>ULP's negotiation method), the ULP transmits a switch PDU
>which indicates it is the last non-RDMA PDU. When the
>other ULP receives the switch PDU, it turns on RDMAP for
>the receive stream.
>

I'm not following how it can be that simple.

If data is transmitted *after* the switching PDU, what
receive queue will it be placed in? The ULP cannot process
the switch-mode request *instantly*, therefore the following
data must be fenced against this transition. Otherwise it
would be at risk of being processed to the non-RDDP TCP
receive queue rather than by the RDMA engine.

The ULP interpretation of the switch-mode request is
asynchronous. Further, because it is ULP specific, the NIC
has no clue that this is in any way special TCP traffic. The
NIC *should* be optimizing placement of the following bytes
by whatever mechanisms it has for non-TCP placement.

At the minimum, the NIC / stack would need the ability to
recall those bytes, and re-interpret them via the DDP
engine. Such a detailed requirement on non RDMA mode
handling of TCP streams would seem to be a heavy burden on
implementations that would probably hope to simply re-use
existing TCP stacks. In particular, it could be very tricky
for a NIC implemented DDP stack to revoke delivery of bytes
to a software TCP/IP stack.

So, which is preferable, forcing ALL NICs to implement both
RDMA and non-RDMA modes at the same level, or requiring that
the following tranwsmit be fenced with regards to the ack?

Caitlin Bestler