|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI draft 02: digests> 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?
Home Last updated: Tue Sep 04 01:06:11 2001 6315 messages in chronological order |