Subject: RE: [rddp] Optional CRC: Proposed Compromise

From: "Barron, Dwight" <[email-masked]>
Date: Wed, 7 May 2003 13:02:41 -0500

Jim, would provide comments on the acceptability of the following clarification points (aka fine print)?

- The CRC option always applies to both directions of a connection
- The CRC field is always present, but sometimes may not be valid
- The disposition of the CRC option is never made available to the ULP

This last item probably deserves some explanation. One of the reasons that I want CRCs mandatory is to stop the proliferation of "sufficient" transport error checking up to the ULP. I believe that one of the reasons you want CRCs optional is that you deem link CRC+TCP checksum "sufficient." In both cases, I don't believe either of us are proposing that the ULP take additional measures. 

Regards,
Dwight

> -----Original Message-----
> From: Williams, Jim [mailto:[email-masked]]
> Sent: Wednesday, May 07, 2003 12:40 PM
> To: [email-masked]
> Subject: [rddp] Optional CRC: Proposed Compromise
> 
> 
> I would like to throw out the following
> proposed compromise position.  I will
> withdraw it if there is strong opposition
> from either side of this discussion.
> 
>   CRC is optional.  If used, CRC coverage
>   must include both header and payload.
>   CRC MUST be used unless BOTH ends of a 
>   connection opt to not use it.
>   An implementation MAY choose to 
>   always require CRC and therefore
>   not implement non-CRC mode.
>   (I.e. optional CRCs are optional
>   to implement, with the default
>   being to use CRCs.)
> 
>   If both ends opt to not use CRCs,
>   then neither header or payload
>   will be covered by CRC.
> 
> I believe this is totally transparent
> and painless to implementers that want
> to always use CRCs.  But it doesn't 
> preclude other vendors that think
> there might be a subset of the market
> that could benefit from software
> implementations not using CRCs.
> 
> My intent is NOT to address the question
> of whether header and payload are 
> covered by the same CRC or different.
> That is a separate discussion.
> 
>  
> _______________________________________________
> 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: Wed, 7 May 2003 23:31:14 -0500

>- The disposition of the CRC option is never made

A receiving ULP needs to be able to determine whether
it can tolerate "transport specific" payload protection.
As outlined in prior posts, there are applications that
*cannot* tolerate the risk of header correction, and unlike
payload protection there is no easy correction for such
applications.

Therefore the option to suppress MPA CRCs would have to
be agreed to by the sending MPA, receiving MPA and
the receiving ULP.

At that point the only "cost" of allowing the option
is the two bits required in the MPA mode mask (I'm
willing to receive/send without CRC). The most that
any implementation would be forced to deal with
suppressed CRCs would be to not set bits, so the
other side knew.

I'm not certain how much the option is really worth
at that point -- but it is certainly minimal cost.

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

---

From: "Somesh Gupta" <[email-masked]>
Date: Thu, 8 May 2003 10:37:34 -0700

I don't think the CRC field should be present if not in use
(It does make sense to have it be present or absent in both
directions at the same time).

There are fairly reasonable scenarios that make it completely
not useful (to be PC here). A combination of IPSec offload that
is likely to become common and free (part of the NIC cost) combined
with the first hack of an iSCSI based storage server is likely to
make IPSec a must have for authentication. This will take care
of worries about integrity as well as resegmenting middle boxes.

As always caveats etc. for something not here.

Somesh

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Barron, Dwight
> Sent: Wednesday, May 07, 2003 11:03 AM
> To: Williams, Jim; [email-masked]
> Subject: RE: [rddp] Optional CRC: Proposed Compromise
>
>
> This last item probably deserves some explanation. One of the
> reasons that I want CRCs mandatory is to stop the proliferation
> of "sufficient" transport error checking up to the ULP. I believe
> that one of the reasons you want CRCs optional is that you deem
> link CRC+TCP checksum "sufficient." In both cases, I don't
> believe either of us are proposing that the ULP take additional measures.
>
> Regards,
> Dwight
>

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 8 May 2003 13:02:22 -0500

>directions at the same time).

Having the field always be present simplifies startup.

If the CRC field is always present, a sender could transmit
the MPA mode frame and the first data frame with a valid
CRC. A valid CRC is acceptable to the other side whether
it support CRC suppression or not.

If the CRC field were to be omitted, not merely voided,
neither side could transmit the first data frame until
after receiving the other's mode frame. That would delay
the start of productive data transfer.

Always having the CRC field present will also simplify
coding. There will be fewer places where the mode will
have to be checked.

Caitlin Bestler

---

From: "Somesh Gupta" <[email-masked]>
Date: Thu, 8 May 2003 11:20:01 -0700

I think it is safe to assume that there is a negotiation
phase of some kind in our future.

As far as advantages/disadvantages are concerned - there 
are both. An addition vector to be allocate/pinned/deallocated
etc is additional cost. On receive side with plain TOE, it
pollutes the data stream.

> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Thursday, May 08, 2003 11:02 AM
> To: [email-masked]
> Cc: Somesh Gupta

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 8 May 2003 13:40:14 -0500

>phase of some kind in our future.

I would be opposed to any MPA modification that prevents
immediate sending of DDP Segments. RDMA is applicable to
a wide variety of protocols to fetch public resources "on
demand", such as HTTP. We cannot assume that all RDMA
applications are predicated with a session setup phase
where client and server both authenticate themselves.
How much validation/handshaking is required is dependent
on the ULP, and should remain there to the greatest
extent that is possible.

All of the options that have been proposed fit within a
single "MPA Mode frame" that would be the first frame
sent in MPA mode. With packing, another MPA frame
containing a DDP Segment could follow within the same
TCP segment.

My enumeration includes the following contents for the
MPA Mode frame:

--  Some sort of signature that makes it unlikely for
    non-MPA traffic to be mistaken for this frame.
    Actually just having a CRC on this frame would
    be a fairly good way to do that, but a straight-
    forward signature may be enough.
--  Receiver Marker Mode preferred.
--  Whether the alternate mode will be accepted.
--  Sender's preferred Marker Mode.
--  Supports CRC voiding on send.
--  Supports CRC voiding on receive.

Such a definition supports immediate transmission of the
first DDP Segment even before receipt of the partner's
MPA Mode frame.

A "quick sender" should be confident that the other end will
accept the "Sender's Preferred Marker Mode". If wrong the
connection will be torn down, and any speculative
transmissions will have been wasted. Unless very confident
the sender SHOULD NOT send extra TCP segments before
confirming the peer's acceptable Marker Modes.

Before receiving confirmation that the peer will work in
voided CRC mode, and frames sent MUST have a valid CRC.
If in fact voided CRC mode is acceptable to both ends
these CRCs will simply not be checked upon receipt.

All of this can be accomplished without requiring a
round-trip delay. I am not aware of any other options
that have even been discussed which would require such a
delay.

Caitlin Bestler