Subject: RE: [rddp] Transport Neutral "Connections"

From: "Shah, Hemal" <[email-masked]>
Date: Fri, 6 Jun 2003 07:53:23 -0700

I think CRC on/off should be an administrative issue. I do not think we
need to add wire protocol behavior for it. I do not think we need to
define MPA mode frame negotiation for it.

An MPA implementation MAY choose to provide the disabling of the MPA CRC
verification for the incoming FPDUs and/or the MPA CRC computation for
the outgoing FPDUs by the means of the local interface or configuration.
If an MPA implementation does not provide this capability, then the MPA
CRC computation/verification will always be performed by the MPA layer.
In any case, the MPA CRC field is always present in the FPDU.

I believe the above is a reasonable compromise for both the hardware and
software implementations.

I strongly prefer that we have to deal with only two modes: Stream mode
and iWARP mode. How the Private Data is exchanged and CRC on/off
capability is communicated is out of the scope of MPA specification.

Hemal 

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Thursday, June 05, 2003 9:17 PM
To: Carrier, John
Cc: [email-masked]
Subject: RE: [rddp] Transport Neutral "Connections"

On 6/5/03, Carrier, John wrote:

>As Paul points out, in the current RDMAP/DDP model there
>is streaming mode and then iWARP mode.  What you are
>suggesting is a third, intermediate mode. The problem is
>that MPA talks directly to DDP and there is no provision
>for a ULP to receive data from DDP unless the ULP has
>pre-posted a receive buffer.  Pre-posting a receive buffer
>implies that the RDMA endpoint has already been created
>for the ULP.

The ULP has authorizes entry to MPA mode and tells the
MPA/stack to expect a confirming MPA Mode frame. A buffer
can easily be provided at that time.

With or without Private Data, any TCP byte stream that
converts to MPA has a series of bytes before MPA mode,
an MPA Mode Frame, and then an MPA mode series of bytes.

That is not changed by the inclusion of Private Data
within the MPA Mode Frame.

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: Caitlin Bestler <[email-masked]>
Date: Fri, 6 Jun 2003 10:12:39 -0500

On 6/6/03, Shah, Hemal wrote:

>I strongly prefer that we have to deal with only two
>modes: Stream mode and iWARP mode. How the Private Data is
>exchanged and CRC on/off capability is communicated is out
>of the scope of MPA specification.

So you are arguing that you cannot enter MPA mode without
fully associating it with an RDMAP/DDP endpoint?

Wouldn't that mean that MPA could *only* be used with
RDMAP/DDP?

The idea of shortening the CRC to cover only the header,
as opposed to omitting it, was rejected because we 
considered it inappropriate for MPA to know how long
the RDMAP/DDP Header was.

But why wouldn't we if the only way to enable MPA
was to associate it with an RDMAP/DDP endpoint?

There is obviously a desire to preserve the draft
RDMAC iWARP verbs. But at least as far as that draft
deals with enabling an LLP Stream, it has failed to
deal with SCTP and fails to cleanly layer DDP over
the LLP.

The proposal to allow Private Data in the MPA Frame
mode was an attempt to *minimize* changes to those verbs,
but merely requiring that MPA be supported *before*
enabling RDMAP/DDP would also solve the problem.

Either solution would work.

I do not think it is appropriate to define MPA in a way
which a) forces iWARP applications to directly use the
LLP themselves for iWARP related functions, and
b) assumes the local interface will horrendously
rototill its *interface* to mandate that MPA, DDP
and RDMAP all be enabled at the same time with a
single user action.

Caitlin Bestler