Subject: [rddp] Option or mandatory CRC in MPA

From: Stephen Bailey <[email-masked]>
Date: Mon, 07 Apr 2003 19:41:43 -0400

Hi,

It seems to me that one significant items holding up RDDP and
specifically MPA, is whether CRC should be optional or mandatory.

At the last IETF David said he would be uncomfortable requiring CRC
protection if a key current client protocol (NFS) is not going to
require the protection when not running on RDDP.  The primary argument
for this is to allow RDDP to cross the transition hurdle more easily
by not punishing software clients.

A majority of implementors want CRC, so clearly many implementations
will support it. There's incentive to implement it, and the penalty in
hardware implementations is negligable.

Implementations that do CRC can generate always and check optionally,
which is easy.

Rather than waiting for NFSv4 to settle the argument, it seems we
could push ahead with a reserved spot in the payload, and negotiable
checking.

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

---

From: Michael Krause <[email-masked]>
Date: Tue, 08 Apr 2003 05:41:19 -0700

>could push ahead with a reserved spot in the payload, and negotiable

In some discussions after the meeting with people in NFSv4, it seemed they 
may be fine with RDDP doing the CRC and letting it be optional at their 
layer.  Agree that NFSv4 workgroup needs to make a recommendation here but 
it is not clear to me that having it required is a major issue at all.  The 
only issue raised was why do it in both layers?   If NFSv4 can make it 
optional similar to how iSCSI can make digests optional then this can be 
resolved as a ULP issue allowing the RDDP implementations to be simplified 
by eliminating the need for negotiation.  Perhaps the workgroup chairs 
could organize a discussion to help get this issue resolved.  I would hate 
to make a change that may not be required at the end of the day in this regard.

Mike

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 8 Apr 2003 12:02:16 -0700

I see some issues in doing the CRC checking as a negotiable feature 
at the MPA level.

Apart from the optionality aspect, I don't quite see how ULP-level
CRC negotiation (such as for iSCSI) can harmoniously work with
an MPA-level negotiation of the same.  There's no issue when it's
negotiated to "No".  But when it's negotiated to "Yes" at the iSCSI-level,
as an example, iSCSI wants to generate and check it - not delegate 
the checking/generation part to MPA even if MPA could optionally
do it.  I suspect this issue is not unique to one ULP - other comments,
particularly from NFS folks, would help here.

AFAICT, the only clean solution is to have the ULP always negotiate 
the usage to "No" (with the knowledge that the transport substrate is
doing it), and have the MPA layer always generate/check CRC.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

---

From: Brent Callaghan <[email-masked]>
Date: Tue, 08 Apr 2003 14:18:31 -0700

NFS can protect its data with an RPCSEC_GSS checksum, though
it's somewhat expensive to do in the host stack, so it's not
commonly used.

Instead, most NFS mounts today rely on the TCP checksum and
link CRC to protect data payload.

I doubt that many in the NFS community are completely
comfortable relying on the TCP checksum.  If RDDP provides
a 32 bit CRC that's implemented in hardware, then I'm sure
NFS would use it.

But given that NFS is already widely used over regular TCP,
I'm not sure there's enough support to make an RDDP CRC mandatory,
and a performance hurdle for host stack RDDP implementations.

	Brent

---

From: Michael Krause <[email-masked]>
Date: Wed, 09 Apr 2003 06:28:40 -0700

>and a performance hurdle for host stack RDDP implementations.

- The hardware cost is viewed as rather trivial - easier to always 
implement than to have optional.

- Data integrity is a major issue for customers these days.  Having the 
added CRC protection is critical as illustrated by various past discussions 
on the IPS reflector.

- If I recall, doesn't SCTP require a mandatory CRC?  If that is the case, 
wouldn't it be best to have a single "method" be used by all protocols to 
allow ULPs to migrate between the two with minimum functional deltas where 
possible thus mandatory CRC?

Mike

>         Brent
>
>
>Mallikarjun C. wrote:
>>I see some issues in doing the CRC checking as a negotiable feature at 
>>the MPA level.
>>as an example, iSCSI wants to generate and check it - not delegate the 
>>checking/generation part to MPA even if MPA could optionally
>>AFAICT, the only clean solution is to have the ULP always negotiate the 
>>usage to "No" (with the knowledge that the transport substrate is
>>Hewlett-Packard MS 5668 Roseville CA 95747
>>[email-masked]
>>
>>----- Original Message ----- From: "Stephen Bailey" <[email-masked]>
>>To: <[email-masked]>

---

From: Mike Eisler <[email-masked]>
Date: Wed, 09 Apr 2003 17:26:55 -0700

> it's somewhat expensive to do in the host stack, so it's not

The RPCSEC_GSS checksum is for protection from malicious
tampering by attackers. Whereas a CRC is more protection from
non-malicious tampering.  They are solving two different problems.

> a 32 bit CRC that's implemented in hardware, then I'm sure

Agreed. Also the analysis done by the iSCSI group is pretty convincing that
the 16 bit TCP checksum is an accident waiting to happen.
It's amazing that IETF has not added a better CRC to TCP.

> But given that NFS is already widely used over regular TCP, 

Sure but widely used over slower media than what RDDP is
trying to enable. Increase the speed, and the odds of corruption
increase.