Re: FCIP: Comment 109

[Ralph Weber <ralphoweber@compuserve.com>]

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

"Mallikarjun C." wrote:

>
> 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?
> >
> >
> >