RE: New iFCP draft

[Charles Monia <cmonia@NishanSystems.com>]

Hi Stephen:

Thanks for the input.

A little history:

We added the CRCs to buttress end-to-end rather than on-the-wire error
detection (although that's an important consideration of course). That is,
we wanted to give implementations a way to protect the frame while it
traversed the sending and receiving gateways and other way points in
between.

We had decided to make CRCs optional to accomodate those who felt that the
TCP/IP checksum was adequate for this purpose and easier to deal with. 

In rethinking the issue, my preference now would be to make it mandatory as
you suggest.  If it were to remain optional, I'd propose to change the spec
as follows.

1.  All frames will contain CRC fields.  As described below, the fields may
or may not contain valid CRCs.

2.  A sending gateway that supports CRCs can always unconditionally generate
and include them in outgoing frames. A CRC VALID bit in the encapsulation
header defines whether or not the CRC fields in the frame are valid. 

3. A gateway that supports CRCs will conditionally check the frame based on
the setting of the CRC VALID bit.  A gateway that does not support CRCs
will, of course, bypass such checks.

With regard to the Fibre Channel undetected error rate you mention, it's my
impression that the deployed systems are exteremely solid.  As I understand
it, the 10^^-12 error rate was set on the basis of testability concerns
rather than physical limitations in the technology. 

Charles

PS:  In my opinion, any feedback of this type should be interpreted in the
light you describe.

> -----Original Message-----
> From: ELLIOTT,STEPHEN (HP-Roseville,ex1) 
> [mailto:stephen_elliott@hp.com]
> Sent: Thursday, January 11, 2001 2:41 PM
> To: ips@ece.cmu.edu
> Subject: New iFCP draft
> 
> 
> With regards to the new iFCP draft
> 
> 5.3        Trailing iFCP CRC
> 
>     This original Fibre Channel CRC shall not be encapsulated into the
>     iFCP message.  Rather, iFCP MAY use a 32-bit field 
> containing a CRC
>     calculated over the data contained in the frame from the iFCP
>     AUGMENTED DATA to the iFCP Payload (inclusive).  This includes the
>     Fibre Channel header and payload.  The iFCP CRC follows the iFCP
>     payload, and the CRC algorithm is the same used for the 
> Frame Check
>     Sequence (FCS) of IEEE 802.3 Ethernet frames.  A bit in the iFCP
>     FLAGS field in the iFCP header indicates the presence or 
> absence of
>     this 32-bit trailing CRC. 
> 
> I would suggest "Rather, iFCP MUST use a 32-bit field 
> containing a CRC ..."
> unless ethernet provides an equivalent CRC elsewhere.  The 
> reason is that I
> believe gigabit ethernet uses the same physical layer as 
> fibre channel.
> This physical layer is specified for fibre channel to have a 
> data bit loss
> rate of 1 in 10^12 or less, and is not "perfect".  I think the CRC is
> designed to throw out these imperfect frames instead of 
> resulting in data
> corruption.  Without the CRC, physical layer imperfections within
> fibre-channel specificaiton may lead to data corruption.
> 
> Also, I am not intending to show preference for iSCSI or iFCP 
> with this
> email.  I just was skimming over the standard and thought 
> this feedback
> might be helpful.
> 
> Stephen Elliott
>  
>