Subject: [rddp] One vs Two CRCs

From: "Somesh Gupta" <[email-masked]>
Date: Thu, 21 Nov 2002 15:05:15 -0800

After listening to the discussion after Jim William's
presentation at the IETF, I think that having two CRCs
is more flexible than having one CRC.

A single CRC restricts the implementation to one where
the check must be done in-line with the packet ingress -
which in turn implies many other design choices.

A separate header/payload CRC allows the CRC to be done
either at ingress, or at egress to the system. It does
not unduly constrain the implementations that want to
perform their checks only at the ingress. It allows both
unbuffered and buffered models. The only negative
being an extra 4-bytes.

I would suggest mandating the use of IPSec and
not having to worry about CRCs at this layer at all.

Somesh
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 21 Nov 2002 17:18:54 -0800

Uri,
You were going good until you fell into the area of Security.  That will be
a completely different thing.  I strongly suspect that since iSCSI was
required to have IPsec as a MUST implement, that will be our requirement
here.  Now to be fair, you said, below,  "Use of the feature", so
technically you were not at odds to the IETF direction, but I think that
the intent of your message was to exclude it from the MUST implement
requirement.  And that will probably will not pass go.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG 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]

"Uri Elzur" <[email-masked]>@ietf.org on 11/21/2002 03:51:29 PM

Sent by:    [email-masked]

To:    "Somesh Gupta" <[email-masked]>, [email-masked]
cc:
Subject:    RE: [rddp] One vs Two CRCs

There has not been any argument as for the benefit of the additional CRC.
The only argument I hear is implementation. "After listening to many NIC
vendors" in the same meeting, one must reach the conclusion that many other
vendors feel it is easier to implement one CRC.

One CRC is computed the same exact way as an Ethernet CRC - do you mean to
say the Ethernet CRC is harder to do then the 2 CRC scheme?

A separate CRC forces checking the header CRC first (limit the
implementation). IFT forces the implementation to find the beginning of the
message (offset x into the Ethernet frame, varies from frame to frame!) and
compute CRC for few header bytes
then compute Data CRC either as a split compute on the ingess or in one
time on the egress.

IPsec is fully supported by this architecture. Use of it has to do with
security risks and there is no reason to mandate it when the user risk
model is not mandating it.

Uri

-----Original Message-----
From: Somesh Gupta [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 3:05 PM
To: Rddp
Subject: [rddp] One vs Two CRCs

Somesh

---

From: "Williams, Jim" <[email-masked]>
Date: Thu, 21 Nov 2002 20:30:59 -0500

> From: Uri Elzur [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 6:51 PM
> To: Somesh Gupta; [email-masked]

I believe there is an argument both in my draft and my
presentation.  If there is a flaw in this argument,
it would be preferable for you to point out what
aspect of the argument is flawed, rather than
claim the argument doesn't exist.

> The only argument I hear is implementation. 

That is true for may of the features defined in 
the protocols under discussion in this WG.
Implementation issues are valid considerations
as long as they are generic to the protocol
and not a narrow implication of one possible
implementation.

> "After listening to many NIC vendors" in the same meeting, 
> one must reach the conclusion that many other vendors feel it 
> is easier to implement one CRC.

I don't think this should degenerate into a vote, but so
far the NIC vendor representatives I am aware of
are Uri, Pat, Somesh, and myself.  And that looks
like an even split.

------

Having said that, though, I think the source of the
disagreement is a different model of how an RNIC is 
implemented.  It is probably worth drilling into that
a little, and I will attempt to do that at some point
in the near future.  It may boil down to an assessment
of which model is more generic, and which is more
of a point solution.

---

From: "Uri Elzur" <[email-masked]>
Date: Thu, 21 Nov 2002 22:53:37 -0800

Sorry, I have no intention of ignoring your arguments. I was referring to those brought up in the meeting (the presentation has not been submitted to the list so it is hard to refer to it). I was under the impression the arguments got hashed out on this list, before. In any I'll try to summarize it.

1. IFT draft says "First, because of TCP segmentation, the entire payload may not be received together with the header"
this is due to IFT assumptions. With MPA it is expected to be received together. IFT assumes a buffered NIC (or as Dave Black puts it "more buffers") and in this case it makes sense to me more sense, to buffer the whole message and then process it together. IFT assumes in-order ONLY, but can't guarantee that even the whole "DDP header" is in one TCP segment making HW more complex as outlined in my other mail.

2. IFT draft says "The second important reason is that it makes hardware implementations significantly more efficient in that the payload CRC can be calculated as the payload data is streamed from NIC memory to host memory.  This streaming can't take
   place until the header (and therefore the destination host address) has been verified correct."

We differ on this. To me and few other you missed from the list, this implementation is more complex. For instance, every DDP message gets 2 context lookup with IFT while only 1 context lookup is required with MPA. i.e. double computational resources!MPA offers multiple implementation choices - amount of buffering, expect alignment or not, error recovery in case of CRC error with or w/o ULP mechanisms etc. IFT testing is a nightmare as the header can start every where. MPA makes some alignment assumptions that simplify HW in a big way. And still, as Caitlin pointed out, the implantation has plethora of options. 

I'm confident you also noticed the comment in my previous mail, about the algorithmic affinity between MPA and the base Ethernet CRC calculation. "Do you mean to say the Ethernet CRC is harder to do then the 2 CRC scheme? "

Uri
-----Original Message-----
From: Williams, Jim [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 5:31 PM
To: [email-masked]
Subject: RE: [rddp] One vs Two CRCs

------

---

From: "Uri Elzur" <[email-masked]>
Date: Thu, 21 Nov 2002 23:30:31 -0800

John

To me RNIC is a solution for Storage as well as for other types of applications. Assuming iSCSI on RNIC (which is not even dealt with yet) will have the same requirements as iSCSI, you are right. However, does it mean ALL RNICs MUST implement it?

Uri

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 5:19 PM
To: Uri Elzur
Cc: Somesh Gupta; [email-masked]
Subject: RE: [rddp] One vs Two CRCs

Uri,

.
.
.
John L. Hufferd

Uri

-----Original Message-----
From: Somesh Gupta [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 3:05 PM
To: Rddp
Subject: [rddp] One vs Two CRCs

Somesh

---

From: "Renato Recio" <[email-masked]>
Date: Fri, 22 Nov 2002 09:21:25 -0600

Jim,
   In your draft, the header CRC covers the framing header and the DDP
header.  I would expect it to also cover the RDMA (e.g. RDMA Read) header,
if one is present.  Please explain how the a header CRC in the framing
header, that covers the ULP headers, is not a rototilling issue.
Additionally, how does a non-DDP ULP, that wants to use the framing layer,
get its header covered (esp. when the size of the non-DDP ULP's header is
more octets than the DDP header?

   Thanks

Renato J Recio
IBM Distinguished Engineer
Member IBM Academy of Technology
IBM I/O Architecture and Technology
Tel 512-838-3685, T/L 678-3685

                      "Williams, Jim"                                                                                   
                      <Jim.Williams@emu        To:       [email-masked]                                                  
                      lex.com>                 cc:                                                                      
                      Sent by:                 Subject:  RE: [rddp] One vs Two CRCs                                     
                      [email-masked]                                                                                 
                      rg                                                                                                

                      11/21/2002 07:30                                                                                  
                      PM                                                                                                

------

---

From: "Williams, Jim" <[email-masked]>
Date: Fri, 22 Nov 2002 11:28:40 -0500

> From: Renato Recio [mailto:[email-masked]]
> Sent: Friday, November 22, 2002 10:21 AM
> To: [email-masked]
> if one is present.

The proposal is that it would not cover the RDMA header.
The motivation is that only that part of the header which
needs to be verified before placement should be covered.
The RDMA header needs to be verified before delivery and
therefore covering it with the payload CRC is sufficient.

If you disagree with the above, I am certainly open
to alternatives.

>  Please explain how the a header CRC in the framing

Not sure I understand the concern.  The proposed IFT header contains
two length fields.  These fully define what subsets of 
the ULP's PDU are covered by each of the CRCs.

An alternative I was toying with is to eliminate the header
length field and let that be implicit in the DDP header.
This would shorten the IFT header, and clean up the 
alignment, but it dirties up the layering.  Don't know
if that's a good tradeoff or not.

> more octets than the DDP header?

IFT was not intended to be used with any ULP other than DDP.
Is there any reason that non-DDU ULPs should be a goal?
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Williams, Jim" <[email-masked]>
Date: Fri, 22 Nov 2002 12:21:48 -0500

> From: Shah, Hemal [mailto:[email-masked]]
> Sent: Friday, November 22, 2002 11:47 AM
> To: Williams, Jim; [email-masked]
> I would like to add one more point to the debate between two 
> CRCs vs. one
> CRC. In the DDP draft, one of the LLP requirement is LLP MUST 
> provide strong
> digest to cover at least the DDP Segment. The goal is to have 
> the same DDP
> Segment format for different LLPs.
> 
> IFT has two CRCs based proposal for DDP over TCP. SCTP 
> already has a strong
> digest covering the payload. In this case, are we going to 
> have a different
> DDP Segment format for DDP over SCTP mapping or are we going 
> to have two
> CRCs on top of SCTP digest for the DDP over SCTP mapping to 
> maintain the
> same DDP Segment format?

I don't think either one.  The IFT CRCs are not part of the DDP
PDU, therefore the DDP PDU is unchanged from IFT/TCP to SCTP.

This is a similar issue to markers.  Although the markers
are inserted inside the DDP PDU they are not considered part
of that PDU, but rather are part of the MPA layer.

> I would like to hear more thoughts 
> on this one.
> 
> I think with IFT we are roto-tilling DDP and framing layer 
> with digests. 

Not sure exactly what "roto-tilling" is.  But I ragard this
as a much more benign form of roto-tilling than markers.
It's benign in that if we treat the RDMA/DDP/IFT headers
in a merged rather than layered fashion, then there is a 
clean and well defined header format and an unpolluted
payload.  With markers, all formats change depending 
on where the PDU occurs in the TCP stream.  This effectively
precludes a truly merged implementation of MPA and DDP.
MPA must be processed first (to remove markers) before
sense can be made of the DDP layer.

> I would like to have DDP
> functionality cleanly layered above 
> underlying LLP
> that provides strong digest covering the DDP Segment.

Clean is good, but difficult to define objectively.
Ultimately it's a judgement call and a tradeoff. 

> Hemal