Re: FCEncap Last Call Comment 40

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

Ralph,

It's certainly an option to reject the comment, I didn't realize earlier
that you were leaning towards that option.

The reason I took the time to explain my earlier cryptic comments 
was also because I didn't want to leave you with an (incorrect) impression 
that I think the "absolute difference" text change did address the comment.

BTW, it's not exactly an interoperability issue - but an error detection/recovery 
issue.  I would have been much pleased if an assertion was made that the 
probability of "bad sync" is very low and can be simply ignored.

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: "Mallikarjun C." <cbm@rose.hp.com>
Cc: "IPS Reflector" <ips@ece.cmu.edu>
Sent: Wednesday, April 03, 2002 5:22 PM
Subject: Re: FCEncap Last Call Comment 40


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