Subject: Optional CRCs ( was [rddp] Marker Interval )

From: "Williams, Jim" <[email-masked]>
Date: Mon, 24 Feb 2003 17:23:03 -0500

> -----Original Message-----
> From: Barron, Dwight [mailto:[email-masked]]
> Sent: Monday, February 24, 2003 4:28 PM
> To: Somesh Gupta; [email-masked]
> Subject: RE: [rddp] Marker Interval
> 
> 
> There are clearly a wide spectrum of implementation 
> possibilities, but I like to focus on the endpoints first, 
> then determine how many additional click-stops are necessary 
> to adequately support the middle of the spectrum. Clearly, 
> support of an ULP that wants to invoke RDDP over an 
> unmodified TCP stack is an important goal, but optionality 
> isn't free, so let's examine what we are really buying with 
> negotiable marker intervals. I'll assume that the ULP using 
> RDDP wants to see RDDP semantics (whatever that may be) and 
> not interim RDDP headers and components. If you assume this 
> RDDP "library" lives on top of unmodified sockets/TCP, then I 
> believe there is no choice but for a receive stream to a) 
> sequentially read every byte for purposes of CRC calculation 
> and b) copy incoming stream data to separate the RDDP headers 
> from ULP payload. This is especially true of tagged messages 
> where the ULP is using a contiguous memory address range to 
> reference data. On the transmit side, the R!
> DDP library will still have to touch every byte for CRC 
> calculation purposes, 

I think if we are serious about supporting unmodified TCP, then
the CRC should be optional.  NFS typically runs with only TCP/UDP
checksum for protection.  Not a good idea to do this over the 
public internet, but then critical data traveling through
the public internet will (or should) use IPSec protection.

iSCSI is a precedent for optional CRCs.  Data errors in iSCSI
or NFS are equally catastrophic as RDDP.  Tradeoff can be
made by user as to required protection, quality and reliability
of network infrastructure, etc., to decide whether to use CRCs.

> but may try to avoid copying by using 
> multiple send calls. But at what point does copying become 
> cheaper than multiple send calls? Especially if the sender is 
> at least *attempting* to provide header alignment, which 
> would mean adding RDDP headers for each TCP_MAXSEG interval. 
> While we all like to avoid data copies (the whole reason for 
> RDDP to begin with), once we bite the bullet for software 
> CRCs (which is clearly the case with standard sockets), the 
> copy really isn't that painful. 
> 
> Regards,
> Dwight 
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Michael Krause <[email-masked]>
Date: Mon, 24 Feb 2003 15:30:51 -0800

>the public internet will (or should) use IPSec protection.

Isn't SCTP CRC protection required per chunk?  The reason to have a CRC for 
MPA is to provide data integrity below DDP/RDMA  / ULP which has been 
demonstrated as a concern during the development of iSCSI.   Do we really 
need to go back through the entire IPS debate as to why CRCs are good 
things here or accept that a CRC at or above the transport but below 
DDP/RDMA  / ULP is a good thing?

Mike

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 24 Feb 2003 18:15:19 -0600

On 2/24/03, Michael Krause wrote:

>Isn't SCTP CRC protection required per chunk?  The reason
>to have a CRC for MPA is to provide data integrity below
>DDP/RDMA  / ULP which has been demonstrated as a concern
>during the development of iSCSI.   Do we really need to go
>back through the entire IPS debate as to why CRCs are good
>things here or accept that a CRC at or above the transport
>but below DDP/RDMA  / ULP is a good thing?

SCTP provides CRC-32c on the SCTP Packet, not individual Data Chunks.

The SCTP Common Header is defined on page 17:

        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Source Port Number        |     Destination Port Number   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Verification Tag                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Checksum                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
Data Chunks are defined on page 22:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0    | Reserved|U|B|E|    Length                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              TSN                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Stream Identifier S      |   Stream Sequence Number n    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Payload Protocol Identifier                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                 User Data (seq n of Stream S)                 /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

My understanding was that the need for a CRC above TCP had
more to do with its size (16 bits) and algorithm (less sensitive
than a full CRC) than with the layer.

Additionally, because SCTP performs end-to-end PMTU discovery there
would be no reason for a middle box to rebundle SCTP chunks in flight.

Indeed on page 83, RFC2960 specifies that once a user message is
fragmented into Data Chunks it cannot be refragmented. While bundling
is a different process, the spirit of relying upon PMTU discovery
should apply.

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