RE: iSCSI draft 02: digests

["Y P Cheng" <ycheng@advansys.com>]

> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Randall R. Stewart
>
> Mark/Julian:
>
> Mark Bakke wrote:
> >
> > Yes, the connection should not be recovered, but the iSCSI session
> > can be.
>
> I have thought on this for a bit, and it seems to me one must
> have a look at what went wrong if a digest fails and yet TCP
> still delivered the packet. Was it TCP's fault? Well in some
> ways one could answer yes... since what happened is a sequence
> of bit errors was somewhere introduced to the IP packets that
> caused:
>
> A) TCP's (and IP's) checksum to still pass and
> B) The stronger digest protection detected the error.
> <snip> <snip>

I need to add my 2 cents from the HBA's point of view.

There are three levels of protections or CRCs:
1) The media, i.e. Ethernet, 1394, or FC
2) TCP
3) Header and data digests defined in iSCSI

If the HBA hardware detects a media CRC error, since we are not sure that
the HBA is the right recipient of the packet, it is thrown away and the
error is logged.  (Even if the HBA is the right recipient, we are still not
sure if we have the right IP and TCP headers.)

Whereas there is no media CRC error but TCP checksum error is found, the TCP
segment is not processed.  An NACK can be returned to the sender.  (I am not
sure there is the NACK concept in TCP.  In 1394 header and payload are
protected by separate CRC and the NACK is used to start retransmit.)

Finally, without media and TCP errors, we look into the iSCSI header to
validate its digest.  May be someone should show there is significant
benefit of using stronger digest to detects errors not detectable by the
media CRC and TCP checksum.  If so, can we live with the weaker media CRC
and TCP checksum for the IP and TCP headers?