FCEncap Last Call Comment 40

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

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.