Subject: [rddp] Optional CRC: Proposed Compromise

From: "Williams, Jim" <[email-masked]>
Date: Wed, 7 May 2003 13:39:45 -0400

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

---

From: John Hufferd <[email-masked]>
Date: Wed, 7 May 2003 16:20:25 -0700

I now think we are headed in the right direction, and think that Jim and 
Dwight have something that we can get behind and flesh out.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: [email-masked]

"Williams, Jim" <[email-masked]>
Sent by: [email-masked]
05/07/2003 11:47 AM

        To:     [email-masked]
        cc: 
        Subject:        RE: [rddp] Optional CRC: Proposed Compromise

> -----Original Message-----
> From: Barron, Dwight [mailto:[email-masked]]
> Sent: Wednesday, May 07, 2003 2:03 PM
> To: Williams, Jim; [email-masked]
> Subject: RE: [rddp] Optional CRC: Proposed Compromise
> 
> 
> 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

That's what I intended.  Sorry if that was not clear.

> - The CRC field is always present, but sometimes may not be valid

This drops down to a lower level of detail.
However, that approach sounds right to me.

> - The disposition of the CRC option is never made available to the ULP

Likewise the request to opt out of CRC use
should not come from the ULP, or be visible to the ULP.

This doesn't sound like a problem in principle.  TCP typically
doesn't notify the application of what options are negotiated
at the TCP layer.  I don't know, however, what a reasonable
wording of this requirement would be.  It seems a bit strong
to require RDDP to insure that the ULP cannot, by any means, 
determine this.  Certainly vendors providing management
interfaces would want to make this type of information 
available.  Any reasonable wording should be OK, though,
as long as it's not too extreme, and clear on the spirit.

> I believe that one of the reasons you want CRCs 
> optional is that you deem link CRC+TCP checksum "sufficient." 

Sufficient in some cases.  That's the only reason.

> In both cases, I don't believe either of us are proposing 
> that the ULP take additional measures. 

I agree.

---

From: "Teisberg, Robert" <[email-masked]>
Date: Thu, 8 May 2003 13:39:19 -0500

What Caitlin said, and "simplify[ing] coding" applies even more
strongly to hardware implementations than to software.

Somesh, apart from increasing payload space per FPDU by 4 octets,
what is the benefit of eliminating an unused CRC field?  I can't
think of any, and I don't find a 4 octet saving very compelling,
especially in light of the considerations Caitlin brings up.

> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Thursday, May 08, 2003 1:02 PM
> To: [email-masked]
> Cc: Somesh Gupta
> On 5/8/03, Somesh Gupta wrote:
> 
> >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).
> 
> 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
> http://asomi.com/CaitlinBestler/

---

From: "Teisberg, Robert" <[email-masked]>
Date: Thu, 8 May 2003 13:53:32 -0500

> From: Somesh Gupta [mailto:[email-masked]] 
> Sent: Thursday, May 08, 2003 1:20 PM
> To: Caitlin Bestler; [email-masked]
> I think it is safe to assume that there is a negotiation
> phase of some kind in our future.

This seems premature.  Let's be careful about self-fulfilling
prophecies.

> 
> As far as advantages/disadvantages are concerned - there 
> are both. An addition vector to be 
> allocate/pinned/deallocated etc is additional cost. 

I don't see this.  Care to elaborate?

> On 
> receive side with plain TOE, it pollutes the data stream.
> 
> 

How so?  If 4 extra octets at the end of an FPDU are a problem, just
think of them as 4 extra octets preceding the next MPA header.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Barron, Dwight" <[email-masked]>
Date: Thu, 8 May 2003 17:00:55 -0500

I believe the ability of to use IPSEC as a substitute for E2E CRC is not an acceptable tradeoff for the following reasons: 
1) there is no architectural method to discover which streams are actually using
IPSEC at the RDDP/MPA layers. In a previous posting, Somesh stated "There is always an administration/config plane to any and all apps" which I consider to be an implementation
specific knob for the administrator to twist and is not a candidate for becoming an 
architected interface at the RDDP/MPA layers. 
2) the decision to implement IPSEC for free in silicon does not appear to be pervasive in the industry just yet, and is further gated by the deployment of sufficient management
infrastructure to actually use the IPSEC mechanisms. No additional infrastructure is 
needed to use CRCs. 
3) Valid and popular topologies remove the IPSEC engine one or more links from the end node, so it is not a true end-end protection
4) While I believe layering an E2E CRC above TCP at the MPA layer will in fact help detect and diagnose latent faults in the TCP/checksum layer, if it is layered below TCP, as in
IPSEC, I agree with Somesh' earlier comment, it will only encapsulate and deliver the 
latent TCP faults

Regards,
Dwight

> Sent: Thursday, May 08, 2003 12:38 PM
> To: [email-masked]
> 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
> > Jim, would provide comments on the acceptability of the following
> > clarification points (aka fine print)?
> >
> > 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: Williams, Jim [mailto:[email-masked]]
> > > Sent: Wednesday, May 07, 2003 12:40 PM
> > > To: [email-masked]
> > > Subject: [rddp] Optional CRC: Proposed Compromise
> > >
> > >