RE: FCIP: Multiple connections

[Sudhir Srinivasan <SudhirS@trebia.com>]

See comments labeled [Sudhir] below:

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


I think another proposal could be that:

- the reverse direction frames are sent to the same IP address of
  the source of the forward direction.

[Sudhir]
This precludes taking advantage of multi-homed NICs (not that
I see that as very critical, but somebody else might).
I think the real way to solve this problem is to complete
the specification of how discovery on the IP plane will happen.
If there is a way of establishing tunnel context during 
connection setup, then each side can independently enforce 
any property such as "NIC allegiance" as needed rather than 
putting a rather arbitrary blanket requirement in the standard.

- when a new connection is established to recover into, that new
  connection is again to the same IP address and not to a different
  IP address.

[Sudhir]
What if the FCIP device reboots and gets a different IP address
from DHCP? I don't see the need for this.


This removes the possibility of the reverse direction frames landing
on a different NIC/port.

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


-----Original Message-----
From: Sriram Rupanagunta [mailto:sriramr@aarohi-inc.com]
Sent: Thursday, May 17, 2001 4:07 PM
To: Sudhir Srinivasan; 'Venkat Rangan'; ips@ece.cmu.edu
Subject: RE: FCIP: Multiple connections


I agree with Sudhir on this. It is harder to make sure that
both sides adhere to same connection.

- Sriram

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