Subject: RE: [rddp] Header CRC mandatory?

From: "Carrier, John" <[email-masked]>
Date: Thu, 1 May 2003 21:52:00 -0700

On 5/1/03 Jim Williams wrote :
> 
>    1.  Users want the same level of protection for
>        both TCP and SCTP.
> 
>        Why?  Users want sufficient protection to
>        insure that silent data corruption does not
>        occur.  Naive expectation would be that
>        TCP provides 16 bit checksum and SCTP provides
>        32 bit CRC.  Which is required depends on 
>        deployment.  If you really want the same,
>        then SCTP should include a 16 bit checksum
>        in the RDDP mapping layer so that both
>        TCP and SCTP will have the combined protection
>        of both a 32 bit CRC and a 16 bit checksum.
> 
> 

Adding additional CRCs or checksums to DDP does not make sense when SCTP
already has 32 bit CRC protection.   

The layering of DDP over its LLP (SCTP or TCP) is cleaner if the CRC is all
done at the LLP.  Since SCTP already has a CRC, that meant adding a CRC to
MPA.  As a result, there are no LLP-specific options inside DDP--the same
definition of DDP is valid over SCTP as well as TCP/MPA.

--jc

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

---

From: "Williams, Jim" <[email-masked]>
Date: Fri, 2 May 2003 10:38:27 -0400

Caitlin Bestler wrote:
> On 5/1/03, Williams, Jim wrote:
> 
> >       [...] If you really want the same,
> I doubt that the 16 bit TCP checksum adds much "value"
> beyond the CRC32c.

I agree. That was my point.  If you are not getting CRC
escapes, then the 16 bit checksum will catch no errors.
(Hypothetically if you were getting CRC escapes, the 
checksum would have a high probability of catching them.)

Likewise if you are not getting TCP checksum escapes, then
the MPA layer CRC adds no value.

> The concern of providing different levels of protection
> is that it will de facto encourage ULPs to design on
> the assumption of TCP's weak protection.

This might be splitting hairs, but I regard this as 
one level of protection (the transport plus RDDP
WILL be reliable), with an optional number of bits
used to get this level of protection.

If the CRC were mandatory to implement and optional to
use, ULPs will treat the transport as reliable.
 
A more difficult question is how would use of CRC be
negotiated?  Neither the RDDP layer or the ULP layer
will know whether a CRC is needed for a particular
network configuration.  This punts it all the way
up to the system administrator to decide and configure,
which is usually not a good thing.

Perhaps a compromise position here would be that
CRC (both header and payload) are always used
UNLESS one end requests no CRCs, and the other
end consents.  The effectively makes no-CRC mode
optional to implement.  But it at least creates
the negotiation mechanism in case there is market
demand for this.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Uri Elzur" <[email-masked]>
Date: Sun, 4 May 2003 20:11:32 -0700

John

I agree with your reasoning below. 

Would like to add that the subject line mentions "Header CRC", while it
is important to have one CRC that covers the entire DDP message, such
that regardless of ULP used, the _complete_ placement information is
protected. In case the DDP header ONLY is protected, you run into
problems pretty fast. Fr instance, RDMAP which is an official draft of
RDDP WG, has its direct data placement information not fully covered if
Header CRC only is used.

Uri

-----Original Message-----
From: Carrier, John [mailto:[email-masked]] 
Sent: Thursday, May 01, 2003 9:52 PM
To: [email-masked]
Subject: RE: [rddp] Header CRC mandatory?

The layering of DDP over its LLP (SCTP or TCP) is cleaner if the CRC is
all done at the LLP.  Since SCTP already has a CRC, that meant adding a
CRC to MPA.  As a result, there are no LLP-specific options inside
DDP--the same definition of DDP is valid over SCTP as well as TCP/MPA.

--jc

---

From: "Carrier, John" <[email-masked]>
Date: Mon, 5 May 2003 09:59:01 -0700

sorry if I wasn't clear.  

I think the CRC calculation should :
* cover all of the data in the TCP payload 
* be mandatory for RDMA over TCP
* be done by the TCP framing layer below DDP (without any knowledge of the
DDP header or its payload)

--jc

> From: Uri Elzur [mailto:[email-masked]]
> Sent: Sunday, May 04, 2003 8:12 PM
> To: Carrier, John; [email-masked]

---

From: "Hilland, Jeff" <[email-masked]>
Date: Mon, 5 May 2003 14:39:01 -0500

Caitlin brings out an excellent point below.  
How is it that CRC32C is acceptable overhead for SCTP, but it is onerous
for MPA?  
I suppose you could argue that there would be extra touches to host
memory, but realistically even my old laptop's NIC does TCP checksum
offload.

Regards,
Jeff Hilland

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Saturday, May 03, 2003 12:52 PM
To: [email-masked]
Subject: RE: [rddp] Header CRC mandatory?

Reviewing this thread, I am all but convinced that rddp is
not the correct forum for this discussion.

An argument can be made that the need for end-to-end CRCs
may be more an inherited superstition than a real need.
Maybe all need for it did disappear with the ISA bus.

But those issues are not specific to rddp. They apply
to reliable transports in general -- and there should
be a consistent policy on the subject. Whatever need
there is for end-to-end protection, it does not vary
based on the membership of specific Working Groups.

The last word from the transport working group on
the appropriate level of protection for a reliable
transport was that SCTP required CRC32C (RFC 3309).

I believe correct procedure would call for any deviation
from that wisdom to be based upon RDDP specific factors. Shouldn't nny
questions regarding the need for end-to-end CRC protection, in general,
be raised on tsvwg?

Similiarly, if a mandatory CRC32C is acceptable for SCTP
(where software implementations actually dominate), then
how can there be RDDP-specific reasoning that concludes
that CRC32C calculations constitute too much of a burden
on software implementations?

The only RDDP specific issue that I am aware of is that
there is a strong argument that the header protection
is *more* of a requirement for RDDP than for a conventional transport.
With a conventional transport *only* the receiving buffer is ever at
risk. With RDDP all other buffers advertised for the Protection Domain
are also at risk. Whether or not a ULP chooses to trust its peer is a
ULP decision. The point is that for those ULPs that do have trust, an
unchecked RDDP header creates a new risk that is not part of a non-RDMA
transport.

But that, I believe, is ultimately irrelevant unless there
are valid RDDP-specific reasons for concluding that
mandatory CRC32C coverage of the entire payload is
unwarranted.

The arguments I have seen are *not* RDDP-specific.

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