Re: FCEncap Last Call Comment 40

[Ralph Weber <ralphoweber@compuserve.com>]

Mallikarjun,

You appear to be saying that the current FC Frame
Encapsulation text is correct. If that is true,
then I have no problems with keeping the current
text without changes.

You may be saying that the current text is
correct in some situations and wrong in others.
Since I cannot see how the situations are
distinguished by code running in a device,
I would prefer to keep the current (more
conservative) text.

Thanks.

Ralph...

"Mallikarjun C." wrote:

>
> Ralph,
>
> Comments below.
>
> Thanks.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
>
> > Comment 40 Technical
> >
> >    - Section 4, page 9, Synchronized state rules. I think this should
> >      also address what is to be done in case there's a case of "bad
> >      synchronization" when Time Stamp words are valid. For ex., when the
> >      received value is smaller than the received entity's timebase, I
> >      assume it would result in arriving at a huge transit time. While
> >      the huge transit time may cause the frame to be discarded, it isn't
> >      clear to me what may cause the TCP connection drop and a re-synch.
> >
> >    Accepted with the following results
> >
> >    Change the recommended transit time evaluation to use the absolute
> >    value of the time difference.
>
> Okay, I guess the policy to apply when a frame takes too long to transit
> is left to encapsulating protocols to specify.  A couple of comments in this
> regard, noting that it's probably not for FCEncap to act on.
>
> - A larger time stamp indicates a problem with the synchronization (with
>    one exception, see next bullet).  It implies to me that R_A_TOV may be
>    incorrectly applied (the delta between the two bases is either added/subtracted)
>    in the traversal of the FCIP Link/iFCP fabric.  The frame should be
>    dropped in this case.  It would even be desirable to somehow resync
>    the timebases.
>
> - The only legitimate case of time stamp being larger than the receiver's
>    timebase is that of a wraparound.  The frame should not be dropped
>    in this case.