Re: FCIP: Comment 109

["Mallikarjun C." <cbm@rose.hp.com>]

Ralph,

> Interoperability concerns dictate that FCIP must either mandate
> 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
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com


----- Original Message ----- 
From: "Ralph Weber" <ralphoweber@compuserve.com>
To: <ips@ece.cmu.edu>
Cc: "Mallikarjun C." <cbm@rose.hp.com>
Sent: Monday, May 06, 2002 7:22 AM
Subject: Re: FCIP: Comment 109


> 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
> 
> "Mallikarjun C." wrote:
> 
> >
> > 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
> > cbm@rose.hp.com
> >
> > >>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?
> 
> 
>