Subject: FCIP: Comment 109

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 3 May 2002 19:28:21 -0700

Ralph,

> http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf
....
> Please review these comments resolutions to ensure that
> the desired changes are described.

Sorry for the delayed review, I have additional comments on wglc-01
for Comment 109.

Regards.
--
Mallikarjun

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

>>Comment 109 Technical
>> 6.6.1 FCIP Encapsulation of FC Frames
>....
>> The CRCV (CRC Valid) Flag SHALL be set to 0.
>>
>> The CRC field SHALL be set to 0.
>I am surprised that the FCIP encapsulated header is never protected
>by a CRC. The error detection section clearly acknowledges the
>possibility that TCP checksum could be inadequate for certain
>deployments - and even suggests checking the FC frame CRC (sort
>of like a data digest) on reception at the Encapsulated Frame
>Receiver Portal.
>My recommendation is to require an FCIP Entity to employ the header
>CRC if the SF that it receives asks for CRC - IOW, similar to iSCSI's
>approach. So, I guess I am also advocating a new bit in the pFlags
>field to announce this. When this CRC expectation is announced, the
>FC CRC checking test in 6.6.2.2 should also be a mandatory test -from
>the "semi-optional" list it is currently in.
>Accepted with the following result
>Add the following to the new section created in response to comment
>44: "Note: Owing to the limited manner in which the FSF is used and
>the requirement that the FSF be echoed without changes before a TCP
>connection is allowed to carry user data, no error checking beyond
>that provided by TCP is deemed necessary."

Sorry, I missed the earlier discussion on this comment.

My comment was for __all__ FCIP encapsulated headers on all FCIP 
Frames - not just for FSF.  The reference to FSF in my comment was
to suggest how an "I want CRC" demand be communicated at the FCIP
Link establishment time - i.e. the reference was a solution strawman.

I probably missed something critical - could you please comment on
whether or not CRC protection is available on FCIP headers and
help me with a reference if so?

---

From: Ralph Weber <[email-masked]>
Date: Mon, 06 May 2002 09:22:40 -0500

Mallikarjun,

> ... - could you please comment on whether or not CRC protection 
> is available on FCIP headers and help me with a reference if so?

CRC protection is prohibited for FCIP headers as per following
two statements in 6.6.1:

  "The CRCV (CRC Valid) Flag SHALL be set to 0."
  "The CRC field SHALL be set to 0."

It is further worth noting that the error detection algorithms
described in 6.6.2.2 include no provisions for the use of CRCs
but do describe a through FCIP header validation mechanism
based on redundancy.

The recommendation that CRC be used for FCIP headers has been
considered and rejected in the past. The preference for
redundancy validation of FCIP headers is partially described 
in the FC Encapsulation draft section 3.2.1.

   "Header validation based on redundancy is a stepwise process 
   in that the first word is validated, then the second, then 
   the third and so on. A decision that a candidate header is 
   not valid may be reached before the complete header is 
   available."

It should be noted that the Fibre Channel requirements for usage
of its CRC are such that the usage of CRC by FCIP would constitute
the only requirement for CRC hardware in an FCIP device.

Interoperability concerns dictate that FCIP must either mandate
or prohibit use of CRC, so CRC usage is prohibited.

Thanks.

.Ralph

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 6 May 2002 11:08:52 -0700

Ralph,

> or prohibit use of CRC, 

Or adopt a must-implement-may-use policy with the FSF indicating
the choice - which was my strawman.

I was about to be completely satisfied about the redundancy, but I see that with 
the exception of Timestamp - all other fields are redundant.  If the corruption
probability of timestamp (with attendant side effects) is considered insignificant
by everyone else, I wouldn't press this.  Perhaps it is worth noting the lack of 
redundancy for timestamp and leaving it there.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka

---

From: Ralph Weber <[email-masked]>
Date: Mon, 06 May 2002 15:22:13 -0500

Mallikarjun,

The reasons for not worrying about the timestamp are based on
the fact that the range of valid timestamp values is very small
when compared to the total value range (something like 20 in
4 billion) with results as follows:

  1) Changing a valid timestamp into an invalid one is not an
     issue because it is only one of several ways in which a
     potentially good frame can get dropped; and
  2) The chances of changing an invalid timestamp are considered
     very remote because two events are required to cause the
     condition:
     a) the frame transit has to be delayed too long; and
     b) the timestamp has to be altered in just the right way
        without any other alterations occurring.

Thanks.

.Ralph