Re: FCEncap Last Call Comment 40

[Ralph Weber <ralphoweber@compuserve.com>]

Mallikarjun,

The assumption that the transit time is computed by
the FCencap code is not correct. The description of
the transit time basics is located in the FCencap
draft to:

  1) Alert future encapsulating protocols to a
     basic requirement that they must meet; and
  2) Describe those aspects of transit time
     computation (e.g., Synchronized state)
     that are nearly certain to be common to
     all such implementations.

There are other aspects of your note not addressed
by this. I think they are as follows:

> I guess I am suggesting that the FCencap code when it 
> detects a case of bad sync, ...

Short of a crystal ball, exactly how does one detect
the difference between too long a transit time and
bad sync? Is there substantial interoperability benefit 
derived from adding the half page or more of text
required to nail this down? Or, are we forcing the
draft into the "creeping elegance" zone?

> The FCencap text should state more than the "absolute 
> difference" since an absolute difference value figured 
> by the FCencap code in the wraparound case ...

Every time we discuss this, I become more convinced
that attempting to address comment 40 by adding
"absolute value" was a flat out mistake. Shortly,
I will prepare a new revision of the comments
resolution document that simply rejects comment
40, leaving the test to be on the signed difference
as originally written.

However, I have no clue what "wraparound" has to do
with the SNTP "warparound" occurs in 2036 (if I
remember correctly). I see zero reason to get
excited about this because:

  a) Fixing FCIP is going to be the least of the
     IETF's worries at that time; and
  b) I will be either long retired or totally
     out of the picture by then.

Thanks.

.Ralph

"Mallikarjun C." wrote:

>
> Ralph,
>
> Perhaps I wasn't as clear as I should be.
>
> I am assuming in my comments that the transit time is computed in the FCencap
> code.
>
> > > - 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.
>
> I guess I am suggesting that the FCencap code when it detects a case of
> bad sync, should inform that to the encapsulating protocol along with the frame.
> I expect that the encapsulating protocols would drop the frame in this case.
> In addition, I am suggesting that they ideally should also specify a forced resync.
>
> > > - 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.
>
> The FCencap text should state more than the "absolute difference" since an
> absolute difference value figured by the FCencap code in the wraparound
> case and passed on to the encapsulating protocol code would almost guarantee
> that the frame will be discarded there - so I was implying a "wraparound-sensitive"
> transit time computation.
>
> Code running in a device should be able to detect when its timebase wraps
> around, I do not see any issue there....it would need to apply that wraparound
> context to all the frames received with larger time stamp value than the local
> timebase and then discard the context.
>
> Someone may say that the "bad sync" scenario is too hypothetical, but
> I hope the above clarifies my concern in this regard anyway.
>
> Thanks.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com