RE: FCIP: Multiple connections

[Sudhir Srinivasan <SudhirS@trebia.com>]

> Implementing this "flow allegiance" is
> not a significant incremental effort since in order to map all frames of a
> single direction of a flow on to a particular connection, most of the
> work is already done anyway.

I disagree - mapping in one direction only is much 
easier than mapping consistently in both directions 
across multiple vendors' solutions -- both ends have 
to use the same mapping algorithm or have to remember 
a LOT of stuff to do this in an interoperable manner.

Now let's look at the issues you raise.
1. Asymmetric routing: Routers won't distinguish between
   two FCIP connections; so I argue that using a different
   connection does not add routing asymmetry.
2. NIC application - Such devices should be built to ensure
   that the connections don't span IP addresses (NICs) and
   the processing should be done above the TCP port level
   so that using a different TCP port wouldn't matter.
3. Connection failure - even with a single connection, 
   the issue you mention is already there to some extent. 
   One side may terminate the connection and it will take 
   a while for the other side to realize it. Also, ULP
   mechanisms should kick in to contain the damage.

So, in summary, I don't believe these issues are 
sufficient to justify the extra burden that the rule
places on devices or the potential risk of interoperability
problems. 

On the issue of "negotiating", FCIP does not have any notion
of parameter negotiation today, correct?

-----Original Message-----
From: Venkat Rangan [mailto:venkat@rhapsodynetworks.com]
Sent: Thursday, May 17, 2001 11:37 AM
To: 'Sudhir Srinivasan'; 'ips@ece.cmu.edu'
Subject: RE: FCIP: Multiple connections


Sudhir,

For a given FC Flow (indicated by a SID, DID pair of the FC frames),
both forward and reverse directions are mapped to the same connection.
This ensures that:

1. Any TCP congestion related rate adjustment on one direction impacts the
   other direction equally. Although even a single TCP connection is subject
to
   variations introduced due to assymmetric routing, we do not want to
introduce
   more assymmetry by sending forward direction frames of one flow on one
   connection and the reverse on a different connection.

2. By allowing forward and reverse traffic flow on different connections,
   the protocol may exclude implementation of a class of products that
   rely on seeing the forward and reverse traffic on the same NIC where
   the connection is processed. If the connections end up on different
   NICs or ports and the processing is off-loaded to them, then you have
   the need to either exchange state or forward traffic to a common point.

3. Error recovery in the case of TCP connection failure may cause one of the
   two directions to be functional while the other is not. If both
directions
   are mapped to the same connection, such recovery is more easily mapped to
   a link/ISL failure.

If the protocol allows forward and reverse directions of a flow to be mapped
on
different connections, I would like to suggest that there is an option that
allows a pair of FCIP Device Endpoints to negotiate that both directions
must be
mapped on to the same connection. Implementing this "flow allegiance" is
not a significant incremental effort since in order to map all frames of a
single direction of a flow on to a particular connection, most of the
work is already done anyway.

Regards,

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com



-----Original Message-----
From: Sudhir Srinivasan [mailto:SudhirS@trebia.com]
Sent: Monday, May 14, 2001 1:53 PM
To: 'ips@ece.cmu.edu'
Cc: Sudhir Srinivasan
Subject: FCIP: Multiple connections



In Section 5.5, what is the reason to include rule (2)?
Is it not sufficient that frames in each direction be delivered
in order? Physical analogy is to have two half-duplex lines
instead of a full-duplex line. Vendor should have the choice
to go either way.

-Sudhir

Trebia Networks, Inc.                Sudhir.Srinivasan@trebia.com
978-929-0830 x139                   www.trebia.com