Re: FCEncap Last Call Comment 40

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

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

----- 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 1:45 PM
Subject: Re: FCEncap Last Call Comment 40


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