Subject: RE: iFCP:Timeout and Encapsulation (was FC-BB exists, why invent something new?)

From: Charles Monia <[email-masked]>
Date: Tue, 2 Jan 2001 17:31:06 -0800

> -----Original Message-----
> From: Douglas Otis [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2001 10:24 AM
> To: Charles Monia; Y P Cheng; IPS Reflector
> Subject: RE: iFCP: FC-BB exists, why invent something new?
> 
> 
> Charles,
> 
> Assurances are made with the fabric timeout but you do not offer a
> time-stamp to keep this promise.  TCP will try well beyond a FC fabric
> timeout.  A cable swap as example could exceed nominal delays.
> 

We are looking at a number of ways to measure whether or not the underlying
network is performing within the parameters of such a performance guarantee.
We're also considering a capability that allows the system user to set the
required timeouts and establish alarm thresholds and contingency policies.

> Would you see it possible to make a separate proposal to cover just
> encapsulation and another proposal to include iFCP specific 
> link services?
> For those wishing just a tunnel, the encapsulation proposal, 
> with a small
> (perhaps optional) iFCP specific field, could serve both purposes.
> 

We would need to carefully consider the consequences of such a proposal.
I'd be especially concerned about consequences down the road that might
impact the ability to make changes to both protocols over time.  Although I
can't speak for them of course, I suspect the tunneling folks may have a
similar view.

<Material deleted>

Charles

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 3 Jan 2001 11:23:52 -0800

Charles,

> required timeouts and establish alarm thresholds and contingency policies.

Should communication be interrupted and restored using various recovery
techniques, this recovery may violate the time-out limitations important to
FC.  In this case, heuristics of nominal communications would be of no use
in determining if such an event occurred.  Other than placing a time-stamp
within the header, I can not see how to police such a policy of squelching
late frames.  Do you have a better idea?

> can't speak for them of course, I suspect the tunneling folks may have a

A significant portion of encapsulation would satisfy both requirements.  I
would recommend adding an option field in the same manner as TCP to include
your additional requirements.  Do this in a way that allows both uses a
level of extensibility as well as a means to negotiate a level of
compatibility supported at each end.  This would ensure a larger community
of products able to interchange and thereby improving your position within
the market place.  You would still be allowed to add improvements that add
value to your products and improve upon this scheme in the future.

> Charles

Doug